Stockage Premium Azure – Conception sous le signe de la haute performance
S’applique à : ✔️ Machines virtuelles Linux ✔️ Machines virtuelles Windows ✔️ Groupes identiques flexibles ✔️ Groupes identiques uniformes
Cet article fournit des instructions pour la création d’applications hautes performances à l’aide du stockage Premium Azure. Vous pouvez utiliser les instructions fournies dans ce document parallèlement aux bonnes pratiques de performances applicables aux technologies utilisées par votre application. Pour illustrer les instructions, nous utilisons comme exemple un ordinateur SQL Server exécuté sur du stockage Premium.
Bien que cet article couvre plusieurs scénarios de performances au niveau de la couche de stockage, vous devez optimiser la couche Application. Par exemple, si vous hébergez une batterie de serveurs SharePoint sur du stockage Premium, vous pouvez utiliser les exemples SQL Server de cet article pour optimiser le serveur de base de données. Vous pouvez également optimiser le serveur web et le serveur d’applications de la batterie de serveurs SharePoint pour obtenir de meilleures performances.
Cet article vous aidera à répondre à certaines questions courantes relatives à l’optimisation des performances des applications sur le stockage Premium :
- Comment faire pour mesurer les performances de votre application ?
- Pourquoi n’obtenez-vous pas les hautes performances attendues ?
- Quels sont les facteurs qui influencent les performances de votre application sur le stockage Premium ?
- Comment ces facteurs influencent-ils les performances de votre application sur le stockage Premium ?
- Comment faire pour optimiser le nombre d’opérations d’entrée/sortie par seconde (IOPS), la bande passante et la latence ?
Nous fournissons ces instructions spécifiquement pour le stockage Premium, car les charges de travail exécutées sur le stockage Premium sont extrêmement sensibles aux performances. Nous proposons des exemples lorsque cela s’y prête. Vous pouvez également appliquer certaines de ces instructions aux applications qui s’exécutent sur des machines virtuelles IaaS (infrastructure as a service) avec des disques de stockage Standard.
Remarque
Parfois, ce qui semble être un problème de performances des disques est en fait un goulot d’étranglement sur le réseau. Dans ces situations, vous devez optimiser vos performances réseau.
Si vous souhaitez évaluer votre disque, consultez les articles suivants :
- Pour Linux : Créer un benchmark de votre application sur Stockage sur disque Azure
- Pour Windows : Évaluer un disque
Si votre machine virtuelle prend en charge les performances réseau accélérées, veillez à ce que cette accélération soit activée. Si ce n’est pas le cas, vous pouvez l’activer sur les machines virtuelles déjà déployées sur Windows et Linux.
Avant de commencer, si vous débutez avec le stockage Premium, commencez par lire les articles Sélectionner un type de disque Azure pour les machines virtuelles IaaS et Objectifs d’extensibilité et de performances pour les comptes de stockage d’objets blob de pages Premium.
Indicateurs de performances d’une application
Nous évaluons si une application fonctionne bien ou non au moyen d’indicateurs de performances tels que :
- Vitesse à laquelle une application traite une requête d’utilisateur
- Quantité de données qu’une application traite par requête
- Nombre de requêtes traitées par une application pendant une période spécifique
- Durée pendant laquelle un utilisateur doit attendre pour obtenir une réponse après avoir envoyé sa requête
Sur le plan technique, ces indicateurs de performances s’expriment en termes d’IOPS, de débit ou bande passante, et de latence.
Dans cette section, nous abordons les indicateurs de performances courants dans le contexte du stockage Premium. Dans la section Liste de vérification des applications hautes performances pour les disques, vous apprendrez à mesurer ces indicateurs de performances pour votre application. Dans la section consacrée à l’optimisation des performances des applications, vous découvrirez les facteurs qui affectent ces indicateurs de performances et des recommandations afin de les optimiser.
E/S par seconde
Le nombre d’IOPS représente le nombre de requêtes que votre application envoie aux disques de stockage en une seconde. Une opération d’entrée/sortie peut être accessible en lecture ou écriture, et être séquentielle ou aléatoire. Les applications OLTP, comme par exemple un site web de vente en ligne, doivent traiter immédiatement de nombreuses requêtes d’utilisateurs simultanées. Les requêtes d’utilisateurs représentent des transactions d’insertion et de mise à jour qui pèsent lourdement sur la base de données, et que l’application doit traiter rapidement. Pour cette raison, les applications OLTP requièrent un nombre d’IOPS très élevé.
Les applications OLTP gèrent des millions de requêtes d’E/S petites et aléatoires. Si vous possédez une telle application, vous devez concevoir votre infrastructure applicative de manière à optimiser les E/S. Pour plus d’informations sur tous les facteurs à prendre en compte pour obtenir un nombre élevé d’IOPS, consultez Optimiser les performances de l’application.
Lorsque vous attachez un disque de stockage Premium à votre machine virtuelle à grande échelle, Azure provisionne pour vous un nombre garanti d’IOPS conformément à la spécification de disque. Par exemple, un disque P50 provisionne 7 500 IOPS. Chaque taille de machine virtuelle à grande échelle est également associée à une limite spécifique d’IOPS qu’elle peut prendre en charge. Par exemple, une machine virtuelle GS5 Standard a une limite de 80 000 IOPS.
Débit
Le débit, ou bande passante, est la quantité de données que votre application envoie aux disques de stockage durant un intervalle spécifié. Si votre application effectue des opérations d’entrée/sortie avec des tailles d’unité d’E/S importantes, elle aura besoin d’un débit élevé. Les applications d’entrepôt de données ont tendance à émettre des opérations d’analyse intensives qui accèdent simultanément à de grandes quantités de données et exécutent généralement des opérations en bloc. En d’autres termes, ces applications nécessitent un débit plus élevé. Si vous possédez une telle application, vous devez concevoir votre infrastructure de manière à en optimiser le débit. Dans la section suivante, nous décrivons les facteurs que vous devez ajuster pour parvenir à cette optimisation.
Lorsque vous attachez un disque de stockage Premium à une machine virtuelle à grande échelle, Azure provisionne un débit conforme à la spécification de ce disque. Par exemple, un disque P50 provisionne un débit de disque de 250 Mo/sec. Chaque taille de machine virtuelle à grande échelle est également associée à une limite spécifique de débit qu’elle peut prendre en charge. Par exemple, une machine virtuelle GS5 Standard a un débit maximal de 2 000 Mo/sec.
La formule suivante illustre la relation entre le débit et le nombre d’IOPS :
Il est important de déterminer les valeurs optimales de débit et d’IOPS dont a besoin votre application. Lorsque vous essayez d’optimiser l’une de ces valeurs, l’autre est également affectée. Pour plus d’informations sur l’optimisation des IOPS et du débit, consultez Optimiser les performances de l’application.
Latence
La latence est le temps nécessaire à une application pour recevoir une requête unique, l’envoyer aux disques de stockage et transmettre la réponse au client. La latence est une mesure critique des performances d’une application qui s’ajoute à celle des IOPS et du débit. La latence d’un disque de stockage Premium correspond au temps nécessaire pour récupérer les informations d’une requête et les retourner à votre application. Le stockage Premium offre de faibles latences. Les disques Premium sont conçus pour offrir des latences en millisecondes à un chiffre pour la plupart des opérations d’E/S. Si vous activez la mise en cache de l’hôte ReadOnly sur des disques de stockage Premium, vous pourrez obtenir une latence de lecture bien plus faible. Pour plus d’informations sur la mise en cache de disque, consultez Mise en cache du disque.
Lorsque vous optimisez votre application pour augmenter le nombre d’IOPS et le débit, la latence de votre application s’en trouve affectée. Après avoir ajusté les performances de votre application, pensez toujours à évaluer la latence de l’application afin d’éviter un comportement de latence élevée inattendu.
Les opérations de plan de contrôle suivantes sur les disques managés peuvent impliquer le déplacement du disque d’un emplacement de stockage à un autre. Ce déplacement est orchestré via la copie en arrière-plan des données, qui peut prendre plusieurs heures. En règle générale, la durée est inférieure à 24 heures et dépend de la quantité de données dans les disques. Pendant ce temps, votre application peut afficher une latence de lecture supérieure à la normale, car certaines lectures sont redirigées vers l’emplacement d’origine et prennent donc plus de temps.
Il n’y a aucun impact sur la latence d’écriture pendant cette période. Pour des disques SSD Premium v2 et Ultra, si le disque a une taille de secteur de 4K, il connaît une latence en lecture plus élevée. Si le disque a une taille de secteur de 512e, il peut connaître une latence en lecture et écriture plus élevée.
Les opérations de plan de contrôle sont utilisées lorsque vous :
- Mettez à jour le type de stockage.
- Détachez un disque d’une machine virtuelle et attachez-le à une autre.
- Créez un disque managé à partir d’un VHD.
- Créez un disque managé à partir d’un instantané.
- Convertissez des disques non managés en disques managés.
Liste de vérification des applications hautes performances pour les disques
La première étape de la conception d’applications hautes performances exécutées sur le stockage Premium consiste à comprendre les exigences de performances de votre application. Après avoir recueilli ces exigences de performances, vous pourrez optimiser votre application de manière à obtenir les meilleures performances possibles.
Dans la section précédente, nous avons expliqué les indicateurs de performances courants, à savoir les IOPS, le débit et la latence. Vous devez déterminer, parmi ces indicateurs de performances, lesquels sont essentiels à votre application pour fournir l’expérience utilisateur recherchée. Par exemple, un nombre d’E/S par seconde élevé est plus important pour les applications OLTP qui traitent des millions de transactions en une seconde. Un débit élevé est essentiel pour les applications d’entrepôt de données qui traitent de grandes quantités de données en une seconde. Une très faible latence est cruciale pour les applications en temps réel, telles que les sites web de streaming vidéo en direct.
Ensuite, vous devrez mesurer les exigences de performances maximales de votre application tout au long de sa durée de vie. Utilisez l’exemple de liste de vérification suivant comme point de départ. Notez les exigences de performances maximales relevées au cours des périodes de charge de travail normales, des périodes de pointe et des heures creuses. En identifiant les conditions requises pour tous les niveaux de charge de travail, vous pouvez déterminer les exigences de performances globales de votre application.
Par exemple, la charge de travail normale d’un site web d’e-commerce correspond aux transactions habituellement traitées au quotidien au cours d’une année. Les pics de charge du site web correspondent aux transactions traitées pendant la période de Noël ou les périodes de soldes. Les pics de charge ne durent généralement que pendant un temps limité, mais ils peuvent vous obliger à mettre à l’échelle votre application en multipliant au moins par deux sa capacité par rapport à son fonctionnement normal. Déterminez les besoins au 50e percentile, au 90e percentile et au 99e percentile. Ces informations vous permettent d’éliminer les observations aberrantes en termes d’exigences de performances, et de concentrer vos efforts sur l’optimisation des valeurs adéquates.
Liste de contrôle pour les exigences de performances de l’application
| Exigences de performances | 50e centile | 90e centile | 99e centile |
|---|---|---|---|
| Nombre maximal de transactions par seconde | |||
| % d’opérations de lecture | |||
| % d’opérations d’écriture | |||
| % d’opérations aléatoires | |||
| % d’opérations séquentielles | |||
| Taille de requête d’E/S | |||
| Débit moyen | |||
| Débit maximal | |||
| Latence minimale | |||
| Latence moyenne | |||
| Processeur maximal | |||
| Utilisation moyenne de l’UC | |||
| Quantité de mémoire maximale | |||
| Mémoire moyenne | |||
| Profondeur de file d’attente |
Remarque
Réfléchissez à la mise à l’échelle de ces nombres en fonction de la croissance prévue de votre application. Il est judicieux de planifier la croissance, car il pourrait être plus difficile de modifier l’infrastructure ultérieurement afin d’en améliorer les performances.
Si vous avez une application existante et que vous souhaitez migrer vers le stockage Premium, commencez par compléter la liste de vérification précédente pour l’application existante. Développez ensuite un prototype de votre application sur le stockage Premium et concevez l’application d’après les instructions décrites dans la section Optimiser les performances de l’application. L’article suivant décrit les outils que vous pouvez utiliser pour collecter les mesures de performances.
Compteurs de mesure des exigences de performances de l’application
La meilleure façon de mesurer les exigences de performances de votre application consiste à utiliser les outils de monitoring PerfMon fournis par le système d’exploitation du serveur. Vous pouvez utiliser PerfMon pour Windows et iostat pour Linux. Ces outils capturent des compteurs correspondant à chaque mesure expliquée dans la section précédente. Vous devez capturer les valeurs de ces compteurs lorsque votre application exécute ses charges de travail normales, de pointe et d’heures creuses.
Les compteurs PerfMon sont disponibles pour le processeur, pour la mémoire, et pour chaque disque logique et chaque disque physique de votre serveur. Lorsque vous utilisez les disques de stockage premium avec une machine virtuelle, les compteurs de disque physique s’appliquent à chaque disque de stockage premium et les compteurs de disque logique à chaque volume créé sur les disques de stockage premium. Vous devez capturer les valeurs des disques qui hébergent la charge de travail de votre application. S’il existe un mappage un-à-un entre les disques logiques et physiques, vous pouvez consulter les compteurs de disque physique. Sinon, reportez-vous aux compteurs de disque logique.
Sur Linux, la commande iostat génère un rapport d’utilisation du processeur et du disque. Le rapport d’utilisation du disque fournit des statistiques par unité physique ou par partition. Si vous avez un serveur de base de données dont les données et les journaux résident sur des disques distincts, récupérez ces données pour les deux disques. Le tableau suivant décrit les compteurs de disques, de processeurs et de mémoire.
| Compteur | Description | PerfMon | iostat |
|---|---|---|---|
| IOPS ou transactions/sec | Nombre de requêtes d’E/S émises sur le disque de stockage par seconde | Lectures disque/s Écritures disque/s |
tps r/s w/s |
| Opérations de lecture et d’écriture de disque | % d’opérations de lecture et d’écriture exécutées sur le disque | % temps de lecture du disque % temps d’écriture du disque |
r/s w/s |
| Débit | Quantité de données lues ou écrites sur le disque par seconde | Nb d’octets de lecture de disque/s Nb d’octets d’écriture de disque/s |
kB_read/s kB_wrtn/s |
| Latence | Durée totale d’exécution d’une requête d’E/S sur le disque | Temps de lecture moyen du disque/s Temps d’écriture moyen du disque/s |
await svctm |
| Taille des E/S | Taille des requêtes d’E/S émises sur les disques de stockage | Nb moyen d’octets en lecture du disque Nb moyen d’octets en écriture du disque |
avgrq-sz |
| Profondeur de file d’attente | Nombre de requêtes d’E/S en attente de lecture ou d’écriture sur le disque de stockage | Longueur actuelle de la file d’attente du disque | avgqu-sz |
| Quantité de mémoire maximale | Quantité de mémoire nécessaire pour une exécution fluide de l’application | % d’octets validés utilisés | Use vmstat |
| Processeur maximal | Quantité de processeur nécessaire pour une exécution fluide de l’application | % temps processeur | %util |
En savoir plus sur iostat et PerfMon.
Optimiser les performances de l'application
La nature des requêtes d’E/S, la taille de machine virtuelle, la taille de disque, le nombre de disques, la mise en cache du disque, le multithreading et la profondeur de file d’attente représentent les principaux facteurs qui influencent les performances d’une application exécutée sur le stockage Premium. Vous pouvez contrôler certains de ces facteurs avec les dispositifs fournis par le système.
La plupart des applications ne vous permettront peut-être pas de modifier directement la taille d’E/S et la profondeur de file d’attente. Par exemple, si vous utilisez SQL Server, vous ne pouvez choisir ni la taille d’E/S ni la profondeur de file d’attente. SQL Server choisit les valeurs optimales de taille d’E/S et de profondeur de file d’attente de manière à obtenir les meilleures performances. Il est important de comprendre les effets de ces deux types de facteurs sur les performances de votre application, afin que vous puissiez provisionner les ressources appropriées pour répondre à vos besoins de performances.
Dans cette section, reportez-vous à la liste de vérification des exigences de performances de l’application que vous avez créée afin d’identifier le degré nécessaire d’optimisation des performances de votre application. En fonction de la liste de vérification, vous pouvez déterminer quels facteurs de cette section vous devez ajuster.
Pour évaluer les effets de chaque facteur sur les performances de votre application, exécutez les outils de benchmarking sur l’installation de votre application. Pour connaître les étapes à suivre pour exécuter les outils de benchmarking courants sur les machines virtuelles Windows et Linux, consultez les articles relatifs au benchmarking à la fin de ce document.
Aperçu de l’optimisation des IOPS, du débit et de la latence
Le tableau suivant récapitule les facteurs de performances et les étapes nécessaires à l’optimisation des IOPS, du débit et de la latence. Les sections qui suivent ce récapitulatif décrivent en détail chaque facteur.
Pour plus d'informations sur les tailles de machines virtuelles et sur les E/S par seconde, le débit et la latence disponibles pour chaque type de machine virtuelle, consultez Tailles des machines virtuelles dans Azure.
| Facteurs de performances | E/S par seconde | Débit | Latence |
|---|---|---|---|
| Exemple de scénario | Application OLTP d’entreprise nécessitant un taux très élevé de transactions par seconde. | Application d’entreposage de données d’entreprise traitant de grandes quantités de données. | Applications en temps quasi-réel nécessitant une réponse instantanée aux demandes utilisateur, telles que les jeux en ligne. |
| Facteurs de performances | |||
| Taille des E/S | Une plus petite taille d’E/S génère un nombre d’IOPS plus élevé. | Une plus grande taille d’E/S génère un débit plus élevé. | |
| Taille de la machine virtuelle | Utilisez une taille de machine virtuelle qui offre un nombre d’E/S par seconde supérieur aux besoins de votre application. | Utilisez une taille de machine virtuelle qui offre une limite de débit supérieure aux besoins de votre application. | Utilisez une taille de machine virtuelle qui offre une limite de mise à l’échelle supérieure aux besoins de votre application. |
| Taille du disque | Utilisez une taille de disque qui offre un nombre d’E/S par seconde supérieur aux besoins de votre application. | Utilisez une taille de disque qui offre une limite de débit supérieure aux besoins de votre application. | Utilisez une taille de disque qui offre une limite de mise à l’échelle supérieure aux besoins de votre application. |
| Limites de mises à l’échelle des machines virtuelles et des disques | La limite d’IOPS de la taille de machine virtuelle choisie doit être supérieure au nombre total d’IOPS générées par les disques de stockage qui lui sont associés. | La limite de débit de la taille de machine virtuelle choisie doit être supérieure au débit total généré par les disques de stockage Premium qui lui sont associés. | Les limites de mise à l’échelle de la taille de machine virtuelle choisie doivent être supérieures aux limites totales de mise à l’échelle des disques de stockage Premium qui lui sont associés. |
| Mise en cache du disque | Activez le cache ReadOnly sur les disques de stockage Premium avec des opérations de lecture intensives pour obtenir un taux d’IOPS en lecture par seconde plus élevé. | Activez le cache ReadOnly sur les disques de stockage Premium avec des opérations de lecture intensives pour obtenir de très faibles latences en lecture. | |
| Entrelacement de disques | Utilisez plusieurs disques et entrelacez-les pour augmenter la limite combinée de débit et d’IOPS. La limite combinée par machine virtuelle doit être supérieure aux limites combinées des disques premium associés. | ||
| Taille de l’entrelacement | Taille d’entrelacement plus petite pour les petits schémas d’E/S aléatoires associés aux applications OLTP. Utilisez par exemple une taille d’entrelacement de 64 Ko pour une application OLTP SQL Server. | Plus grande taille d’entrelacement pour les grands schémas d’E/S séquentiels associés aux applications d’entrepôt de données. Utilisez par exemple une taille d’entrelacement de 256 Ko pour une application d’entrepôt de données SQL Server. | |
| Multithreading | Utilisez le multithreading pour envoyer un plus grand nombre de requêtes au stockage Premium et augmenter ainsi le débit et le nombre d’IOPS. Sur SQL Server, par exemple, définissez une valeur MAXDOP élevée afin d’allouer davantage de ressources processeur à SQL Server. | ||
| Profondeur de file d’attente | Une plus grande profondeur de file d’attente génère un nombre plus élevé d’IOPS. | Une plus grande profondeur de file d’attente génère un débit plus élevé. | Une plus petite profondeur de file d’attente réduit les latences. |
Nature des requêtes d’E/S
Une requête d’E/S représente une unité d’opération d’entrée/sortie exécutée par votre application. Identifier la nature des requêtes d’E/S (aléatoires ou séquentielles, en lecture ou en écriture, petites ou grandes) vous permet de déterminer les exigences de performances de votre application. Il est important de comprendre la nature des requêtes d’E/S afin de prendre les bonnes décisions lorsque vous concevez votre infrastructure d’applications. Pour bénéficier des meilleures performances possibles, veillez à ce que les E/S soient distribuées de façon uniforme.
La taille des E/S compte parmi les facteurs les plus importants. La taille des E/S correspond à la taille de la requête d’opération d’entrée/sortie générée par votre application. La taille des E/S affecte considérablement les performances, en particulier les IOPS et la bande passante que l’application peut atteindre. La formule suivante montre la relation entre les IOPS, la taille des E/S et la bande passante ou le débit.
Certaines applications vous permettent de modifier leur taille d’E/S, et d’autres non. Par exemple, SQL Server détermine lui-même la taille d’E/S optimale, et ne fournit aux utilisateurs aucun dispositif permettant de la modifier. De son côté, Oracle propose un paramètre appelé DB_BLOCK_SIZE, que vous pouvez utiliser pour configurer la taille de la requête d’E/S de la base de données.
Si vous utilisez une application qui ne permet pas de modifier la taille d’E/S, suivez les indications de cet article pour optimiser les indicateurs de performances clé qui correspondent le mieux à votre application. Par exemple :
- Une application OLTP génère des millions de requêtes d’E/S petites et aléatoires. Pour gérer ces types de requêtes d’E/S, vous devez concevoir votre infrastructure d’applications de manière à augmenter le nombre d’IOPS.
- Une application d’entrepôt de données génère d’importantes requêtes d’E/S séquentielles. Pour gérer ces types de requêtes d’E/S, vous devez concevoir votre infrastructure d’applications de manière à augmenter la bande passante ou le débit.
Si vous utilisez une application qui vous permet de modifier la taille d’E/S, utilisez cette règle générale tout en respectant les autres instructions relatives aux performances.
- Une plus petite taille d’E/S pour générer un nombre d’IOPS plus élevé. Par exemple, 8 Ko pour une application OLTP.
- Une plus grande taille d’E/S pour augmenter la bande passante ou le débit. Par exemple, 1024 Ko pour une application d’entrepôt de données.
Voici un exemple de calcul du nombre d’IOPS et du débit ou de la bande passante pour votre application.
Considérez une application qui utilise un disque P30. Un disque P30 peut atteindre au maximum 5 000 IOPS et 200 Mo de débit/bande passante par seconde. Si votre application exige le nombre maximal d’IOPS du disque P30 et que vous utilisez une taille d’E/S plus petite, comme 8 Ko, la bande passante que vous pouvez obtenir est de 40 Mo/s. Si votre application exige le débit ou la bande passante maximal d’un disque P30 et que vous utilisez une taille d’E/S supérieure, comme 1024 Ko, les IOPS résultantes sont inférieures, par exemple 200 IOPS.
Vous devez donc ajuster la taille d’E/S afin qu’elle réponde aux besoins de votre application tant en terme d’E/S que de débit et de bande passante. Le tableau suivant récapitule les différentes tailles d’E/S en indiquant le nombre d’IOPS et le débit correspondants dans le cas d’un disque P30.
| Spécification de l’application | Taille des E/S | E/S par seconde | Débit/bande passante |
|---|---|---|---|
| Nombre maximal d’E/S par seconde | 8 Ko | 5 000 | 40 Mo/sec |
| Débit maximal | 1024 Ko | 200 | 200 Mo/s |
| Débit maximal + IOPS élevées | 64 Ko | 3 200 | 200 Mo/s |
| IOPS maximales + débit élevé | 32 Ko | 5 000 | 160 Mo/s |
Pour obtenir des valeurs d’IOPS et de bande passante supérieures à la valeur maximale d’un seul disque de stockage Premium, utilisez plusieurs disques Premium entrelacés ensemble. Par exemple, entrelacez deux disques P30 pour obtenir une valeur d’IOPS combinée de 10 000 IOPS ou un débit combiné de 400 Mo/s. Comme expliqué dans la section suivante, vous devez utiliser une taille de machine virtuelle qui prend en charge les IOPS de disque et le débit combinés.
Remarque
Lorsque vous augmentez les IOPS ou le débit, l’autre valeur augmente également. Veillez à ne pas atteindre les limites d’IOPS ou de débit du disque ou de la machine virtuelle lorsque vous augmentez l’une ou l’autre valeur.
Pour évaluer les effets de la taille des E/S sur les performances de l’application, vous pouvez exécuter des outils de benchmarking sur votre machine virtuelle et sur vos disques. Créez plusieurs séries de tests et utilisez une taille d’E/S différente pour chaque exécution afin d’en déterminer l’effet. Pour plus d’informations, consultez les articles relatifs au benchmarking à la fin de ce document.
Tailles des machines virtuelles à grande échelle
Lorsque vous commencez la conception d’une application, l’une des premières choses à faire est de choisir une machine virtuelle qui hébergera votre application. Le stockage Premium est fourni avec des tailles de machine virtuelle à grande échelle capables d’exécuter des applications exigeant une plus grande puissance de calcul et de hautes performances d’E/S du disque local. Ces machines virtuelles se caractérisent par des processeurs plus rapides, un rapport mémoire-cœur plus élevé et l’utilisation d’un disque SSD comme disque local. Les machines virtuelles de la série DS et GS sont des exemples de machines virtuelles à grande échelle prenant en charge le stockage Premium.
Ces machines virtuelles sont disponibles en différentes tailles, avec un nombre de cœurs de processeur, une mémoire, un système d’exploitation et une taille de disque temporaire différents. Chaque taille de chaque machine virtuelle a également un nombre maximal de disques de données que vous pouvez attacher à la machine virtuelle. La taille de machine virtuelle choisie affecte la capacité de traitement, de mémoire et de stockage disponible pour votre application. Elle affecte également le coût de calcul et de stockage. Par exemple, les spécifications suivantes concernent la plus grande taille de machine virtuelle dans une série DS et une série GS.
| Taille de la machine virtuelle | Cœurs d’unité centrale | Mémoire | Tailles du disque de la machine virtuelle | Disques de données max. | Taille du cache | E/S par seconde | Limites d’E/S du cache de bande passante |
|---|---|---|---|---|---|---|---|
| Standard_DS14 | 16 | 112 Go | OS = 1023 Go SSD local = 224 Go |
32 | 576 Go | 50 000 E/S par seconde 512 Mo/s |
4 000 IOPS et 33 Mo/s |
| Standard_GS5 | 32 | 448 Go | OS = 1023 Go SSD local = 896 Go |
64 | 4 224 Go | 80 000 E/S par seconde 2 000 Mo/sec |
5 000 IOPS et 50 Mo/s |
Pour afficher la liste complète de toutes les tailles de machine virtuelle Azure disponibles, consultez Tailles des machines virtuelles dans Azure. Choisissez une taille de machine virtuelle capable de s’adapter aux exigences de performances souhaitées de votre application. Prenez également en compte les considérations importantes suivantes lorsque vous choisissez des tailles de machine virtuelle.
Limites de mise à l’échelle
Les limites d’E/S par seconde par machine virtuelle et par disque sont différentes et indépendantes les unes des autres. Vérifiez que l’application génère un nombre d’IOPS dans les limites de la machine virtuelle et des disques Premium qui lui sont associés. Dans le cas contraire, les performances de l’application seront limitées.
Par exemple, supposons une application exigeant un maximum de 4 000 E/S par seconde. Pour atteindre ce niveau, vous devez provisionner un disque P30 sur une machine virtuelle DS1. Le disque P30 peut fournir jusqu’à 5 000 E/S par seconde. En revanche, la machine virtuelle DS1 est limitée à 3 200 E/S par seconde. Par conséquent, les performances de l’application sont contraintes par la limite de la machine virtuelle à 3 200 IOPS et les performances sont détériorées. Pour éviter cette situation, choisissez des tailles de machine virtuelle et de disque qui satisfont toutes deux aux exigences de l’application.
Coût d’exploitation
Dans de nombreux cas, il est possible que le coût global d’exploitation lié à l’utilisation du stockage Premium soit inférieur à celui associé à l’utilisation du stockage Standard.
Imaginez par exemple une application nécessitant 16 000 E/S par seconde. Pour atteindre ces performances, vous avez besoin d’une machine virtuelle IaaS Azure Standard_D14, qui peut délivrer 16 000 IOPS maximum en utilisant 32 disques de stockage standard de 1 To. Chaque disque de stockage standard de 1 To peut atteindre un maximum de 500 IOPS.
- Le coût mensuel estimé de cette machine virtuelle est de 1570 $.
- Le coût mensuel de 32 disques de stockage standard est de 1638 $.
- Le coût total mensuel estimé est donc de 3 208 $.
Si vous hébergez la même application sur du stockage Premium, vous avez besoin d’une plus petite taille de machine virtuelle et de moins de disques de stockage Premium, ce qui réduit le coût global. Une machine virtuelle Standard_DS13 peut couvrir les 16 000 IOPS requis avec quatre disques P30. La machine virtuelle DS13 délivre 25 600 IOPS au maximum, et chaque disque P30 délivre 5 000 IOPS. Globalement, cette configuration peut atteindre 5 000 x 4 = 20 000 E/S par seconde.
- Le coût mensuel estimé de cette machine virtuelle est de 1003 $.
- Le coût mensuel de quatre disques de stockage Premium P30 est de 544,34 $.
- Le coût total mensuel estimé est donc de 1544 $.
Le tableau suivant récapitule la répartition des coûts de ce scénario pour le stockage Standard et Premium.
| Coût mensuel | standard | Premium |
|---|---|---|
| Coût de la machine virtuelle par mois | 1 570,58 USD (Standard_D14) | 1 003,66 USD (Standard_D13) |
| Coût des disques par mois | 1 638,40 $ (32 disques de 1 To) | 544,34 $ (4 disques P30) |
| Coût global par mois | 3 208,98 $ | 1 544,34 $ |
Distributions Linux
Avec le stockage Premium, vous obtenez le même niveau de performances pour les machines virtuelles exécutant Windows et Linux. Nous prenons en charge de nombreuses versions de distributions Linux. Pour plus d’informations, consultez Distributions Linux approuvées sur Azure.
Les différentes distributions sont mieux adaptées à différents types de charges de travail. Vous observerez différents niveaux de performances en fonction de la distribution sur laquelle votre charge de travail est exécutée. Testez les distributions Linux avec votre application et choisissez celle qui vous convient le mieux.
Lorsque vous exécutez Linux avec du stockage Premium, vérifiez les dernières mises à jour relatives aux pilotes requis pour garantir de meilleures performances.
Tailles de disques Stockage Premium
Le stockage Premium offre une diversité de tailles et vous permet de choisir celle qui répond le mieux à vos besoins. Chaque taille de disque a une limite de mise à l’échelle bien spécifique pour le nombre d’IOPS, la bande passante et le stockage. Choisissez la taille de disque de stockage Premium adaptée aux exigences de l’application et à la taille de machine virtuelle à grande échelle. Le tableau suivant présente les tailles de disque et leurs capacités. Les tailles P4, P6, P15, P60, P70 et P80 ne sont actuellement prises en charge que par la fonctionnalité Disques managés.
| Tailles de disque SSD Premium | P1 | P2 | P3 | P4 | P6 | P10 | P15 | P20 | P30 | P40 | P50 | P60 | P70 | P80 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Taille du disque (Gio) | 4 | 8 | 16 | 32 | 64 | 128 | 256 | 512 | 1 024 | 2 048 | 4 096 | 8 192 | 16 384 | 32 767 |
| IOPS approvisionnés de base par disque | 120 | 120 | 120 | 120 | 240 | 500 | 1 100 | 2 300 | 5 000 | 7 500 | 7 500 | 16 000 | 18 000 | 20 000 |
| **IOPS approvisionnés étendus par disque | N/A | N/A | N/A | N/A | N/A | N/A | N/A | N/A | 8,000 | 16 000 | 20 000 | 20 000 | 20 000 | 20 000 |
| Débit approvisionné de base par disque | 25 Mo/s | 25 Mo/s | 25 Mo/s | 25 Mo/s | 50 Mo/s | 100 Mo/s | 125 Mo/s | 150 Mo/s | 200 Mo/s | 250 Mo/s | 250 Mo/s | 500 Mo/s | 750 Mo/s | 900 Mo/s |
| **Débit provisionné étendu par disque | N/A | N/A | N/A | N/A | N/A | N/A | N/A | N/A | 300 Mo/s | 600 Mo/s | 900 Mo/s | 900 Mo/s | 900 Mo/s | 900 Mo/s |
| Nb max. d’iOPS de rafale par disque | 3 500 | 3 500 | 3 500 | 3 500 | 3 500 | 3 500 | 3 500 | 3 500 | 30 000* | 30 000* | 30 000* | 30 000* | 30 000* | 30 000* |
| Débit max. de rafale par disque | 170 Mo/s | 170 Mo/s | 170 Mo/s | 170 Mo/s | 170 Mo/s | 170 Mo/s | 170 Mo/s | 170 Mo/s | 1 000 Mo/s* | 1 000 Mo/s* | 1 000 Mo/s* | 1 000 Mo/s* | 1 000 Mo/s* | 1 000 Mo/s* |
| Durée maximale de rafale | 30 min | 30 min | 30 min | 30 min | 30 min | 30 min | 30 min | 30 min | Illimité* | Illimité* | Illimité* | Illimité* | Illimité* | Illimité* |
| Éligible pour la réservation | Non | Non | Non | Non | Non | Non | Non | Non | Oui, jusqu’à un an | Oui, jusqu’à un an | Oui, jusqu’à un an | Oui, jusqu’à un an | Oui, jusqu’à un an | Oui, jusqu’à un an |
*S’applique uniquement aux disques avec la fonction de bursting à la demande activée.
** S’applique uniquement aux disques sur lesquels Performance plus (préversion) est activé.
Le nombre de disques que vous choisissez dépend de la taille de disque choisie. Vous pouvez utiliser un seul disque P50 ou plusieurs disques P10 pour répondre aux besoins de votre application. Tenez compte des remarques ci-dessous pour faire votre choix.
Limites de mise à l’échelle (IOPS et débit)
Les limites d’IOPS et de débit de chaque taille de disque Premium sont différentes et indépendantes des limites de mise à l’échelle de la machine virtuelle. Vérifiez que le nombre total d’IOPS et le débit total des disques respectent bien les limites de mise à l’échelle de la taille de machine virtuelle choisie.
Par exemple, si votre application requiert un débit maximum de 250 Mo/s et que vous utilisez une machine virtuelle DS4 avec un seul disque P30, la machine virtuelle peut délivrer un débit allant jusqu’à 256 Mo/s. Cependant, un disque P30 a une limite de débit de 200 Mo/s. Ainsi, l’application est contrainte à 200 Mo/s en raison de la limite du disque. Pour contourner cette limite, provisionnez plusieurs disques de données sur la machine virtuelle ou redimensionnez vos disques de P40 à P50.
Remarque
Les lectures traitées par le cache n’étant pas incluses dans les IOPS et le débit de disque, elles ne sont pas soumises aux limites de disque. Le cache a sa propre limite de débit et d’IOPS pour chaque machine virtuelle.
Par exemple, les lectures et écritures sont initialement de 60 Mo/s et 40 Mo/s, respectivement. Au fil du temps, le cache augmente et sert de plus en plus de lectures. Vous pouvez alors obtenir un plus grand débit en écriture à partir du disque.
Nombre de disques
Déterminez le nombre de disques dont vous avez besoin en évaluant les besoins de l’application. Chaque taille de chaque machine virtuelle est limitée quant au nombre de disques que vous pouvez lui associer. En règle générale, ce nombre est égal à deux fois le nombre de cœurs. Assurez-vous que la taille de machine virtuelle que vous choisissez est capable de prendre en charge le nombre de disques nécessaires.
N’oubliez pas que les disques de stockage Premium délivrent des performances supérieures à celles des disques de stockage Standard. Si vous migrez votre application d’une machine virtuelle IaaS Azure utilisant le stockage Standard vers le stockage Premium, vous aurez probablement besoin de moins de disques Premium pour atteindre des performances identiques ou supérieures pour votre application.
Mise en cache du disque
Les machines virtuelles à grande échelle qui utilisent le stockage Premium ont une technologie de mise en cache à plusieurs niveaux appelée BlobCache. BlobCache utilise une combinaison de la RAM de l’hôte et d’un SSD local pour la mise en cache. Ce cache est disponible pour les disques persistants de stockage Premium et pour les disques locaux de la machine virtuelle. Par défaut, ce paramètre de cache est défini sur ReadWrite pour les disques du système d’exploitation et sur ReadOnly pour les disques de données hébergés sur stockage Premium. Lorsque la mise en cache du disque est activée sur les disques de stockage Premium, les machines virtuelles à grande échelle peuvent atteindre des niveaux de performances extrêmement élevés qui dépassent les performances du disque sous-jacent.
Avertissement
La mise en cache de disque n’est pas prise en charge pour les disques de 4 Tio et plus. 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.
La modification du paramètre de cache d’un disque Azure détache et rattache le disque cible. S’il s’agit du disque du système d’exploitation, la machine virtuelle redémarre. Arrêtez toutes les applications et services qui risquent d’être affectés par cette indisponibilité avant de modifier le paramètre de cache du disque. Le non-respect de ces recommandations peut entraîner une altération des données.
Pour en savoir plus sur le fonctionnement de BlobCache, consultez le billet de blog interne sur le stockage Premium Azure.
Il est important d’activer la mise en cache sur le jeu de disques approprié. Le fait de devoir activer ou non la mise en cache du disque sur un disque Premium dépend du modèle de charge de travail géré par ce disque. Le tableau suivant indique les paramètres de cache par défaut pour les disques du système d’exploitation et les disques de données.
| Type de disque | Paramètre de cache par défaut |
|---|---|
| Disque de système d’exploitation | Lecture/écriture |
| Disque de données | Lecture seule |
Nous recommandons les paramètres de cache de disque suivants pour les disques de données.
| Paramètre de mise en cache du disque | Conditions recommandées d’utilisation de ce paramètre |
|---|---|
| Aucune | Configurer le cache hôte sur None pour les disques en lecture seule et les disques gourmands en écriture. |
| Lecture seule | Configurer le cache hôte sur ReadOnly pour les disques en lecture seule et les disques en lecture/écriture. |
| Lecture/écriture | Configurer le cache hôte sur ReadWrite uniquement si votre application gère correctement l’écriture des données mises en cache sur les disques persistants lorsque cela est nécessaire. |
Lecture seule
En configurant une mise en cache ReadOnly sur des disques de données de stockage Premium, vous pouvez obtenir une faible latence de lecture et de très hautes performances d’IOPS et de débit en lecture pour votre application pour deux raisons :
- Les lectures effectuées à partir du cache, qui se trouve sur la mémoire de la machine virtuelle et sur le SSD local, sont beaucoup plus rapides que les lectures effectuées à partir du disque de données, qui réside sur Stockage Blob Azure.
- Le stockage Premium ne tient pas compte des lectures traitées à partir du cache pour le calcul du nombre d’IOPS et du débit du disque. Pour cette raison, votre application peut délivrer de meilleures performances totales en termes d’IOPS et de débit.
Lecture/écriture
Par défaut, la mise en cache ReadWrite est activée sur les disques du système d’exploitation. Nous avons récemment ajouté la prise en charge de la mise en cache ReadWrite sur les disques de données. Si vous utilisez la mise en cache ReadWrite, vous devez disposer d’un moyen approprié d’écrire les données du cache sur des disques persistants. Par exemple, SQL Server gère lui-même l’écriture de données mises en cache sur les disques de stockage persistants. L’utilisation d’un cache ReadWrite avec une application qui ne gère pas la persistance des données requises peut entraîner des pertes de données en cas de panne de la machine virtuelle.
Aucune
Actuellement, l’option Aucune n’est prise en charge que sur les disques de données. Elle n’est pas prise en charge sur les disques du système d’exploitation. Si vous définissez le paramètre None sur un disque de système d’exploitation, il est remplacé en interne et défini sur ReadOnly.
En guise d’exemple, vous pouvez appliquer ces instructions à une instance de SQL Server exécutée sur du stockage Premium en effectuant ces étapes :
- Configurez le cache ReadOnly sur les disques de stockage Premium qui hébergent des fichiers de données.
- Les lectures rapides à partir du cache réduisent le temps de requête de SQL Server, car les pages de données sont récupérées à partir du cache plus rapidement que lorsque l’opération s’effectue directement à partir des disques de données.
- Le traitement des lectures à partir du cache signifie que les disques de données Premium délivrent un débit supplémentaire. SQL Server peut utiliser ce débit supplémentaire pour la récupération d’un plus grand nombre de pages de données et d’autres opérations telles que la sauvegarde/restauration, les charges de traitement par lots et les reconstructions d’index.
- Choisissez l’option None pour le cache sur les disques de stockage Premium qui hébergent les fichiers journaux.
- Les fichiers journaux ont principalement des opérations intensives en écriture. Ils ne tirent donc aucun bénéfice du cache ReadOnly.
Optimiser les performances sur les machines virtuelles Linux
Pour tous les disques SSD Premium ou disques Ultra, vous pourrez peut-être désactiver les barrières pour les systèmes de fichiers sur le disque afin d’améliorer les performances lorsque l’on sait qu’il n’existe aucun cache susceptible de perdre des données. Si la mise en cache de disque Azure est définie sur ReadOnly ou None, vous pouvez désactiver les barrières. En revanche, si la mise en cache est définie sur ReadWrite, les barrières doivent rester activées pour garantir une durabilité d’écriture. Les barrières sont généralement activées par défaut, mais vous pouvez les désactiver en appliquant l’une des méthodes suivantes, en fonction du type de système de fichiers :
- reiserFS : utilisez l’option de montage barrier=none pour désactiver les barrières. Pour activer explicitement les barrières, utilisez barrier=flush.
- ext3/ext4 : utilisez l’option de montage barrier=0 pour désactiver les barrières. Pour activer explicitement les barrières, utilisez barrier=1.
- XFS : utilisez l’option de montage nobarrier pour désactiver les barrières. Pour activer explicitement les barrières, utilisez barrier. À compter de la version 4.10 du noyau Linux principal, la conception du système de fichiers XFS garantit toujours la durabilité. La désactivation des barrières n’a aucun effet et l’option nobarrier est déconseillée. Toutefois, certaines distributions Linux peuvent avoir rétro-porté les modifications apportées à une mise en production de distribution avec une version de noyau antérieure. Contactez votre fournisseur de distribution pour connaître l’état de la distribution et de la version que vous exécutez.
Entrelacement de disques
Lorsqu’une machine virtuelle à grande échelle est connectée à plusieurs disques de stockage Premium persistants, les disques peuvent être entrelacés ensemble pour agréger les IOPS, la bande passante et la capacité de stockage.
Sous Windows, vous pouvez utiliser les espaces de stockage pour entrelacer les disques. Vous devez configurer une seule colonne pour chaque disque dans un pool. Dans le cas contraire, les performances globales du volume entrelacé peuvent être limitées, en raison d’une distribution inégale du trafic parmi les disques.
En utilisant l’interface utilisateur du Gestionnaire de serveur, vous pouvez définir un nombre maximal de 8 colonnes au total pour un volume agrégé par bandes. Lorsque vous attachez plus de huit disques, utilisez PowerShell pour créer le volume. Avec PowerShell, vous pouvez définir un nombre de colonnes égal au nombre de disques. Par exemple, s’il existe 16 disques dans un agrégat unique, spécifiez 16 colonnes dans le paramètre NumberOfColumns de la cmdlet PowerShell New-VirtualDisk.
Sous Linux, utilisez l’utilitaire MDADM pour entrelacer les disques. Pour connaître les étapes d’entrelacement de disques sur Linux, consultez Configurer RAID logiciel sur Linux.
Taille de l’entrelacement
La taille d’entrelacement constitue un facteur important dans la configuration de l’entrelacement de disques. La taille d’entrelacement ou la taille de bloc représente la plus petite partie des données qu’une application peut traiter sur un volume entrelacé. La taille d’entrelacement que vous configurez varie selon le type d’application et le modèle de demande associé. Si vous choisissez une taille d’entrelacement incorrecte, vous risquez de rencontrer un défaut d’alignement des E/S, ce qui conduirait à une dégradation des performances de votre application.
Par exemple, si une requête d’E/S générée par votre application est supérieure à la taille d’entrelacement de disque, le système de stockage l’écrit au-delà des limites d’unité de bande sur plusieurs disques. Au moment d’accéder aux données, il doit effectuer une recherche sur plusieurs unités de bande pour exécuter la requête. L’effet cumulatif de ce comportement peut entraîner une dégradation significative des performances. En revanche, si la taille de la requête d’E/S est inférieure à la taille d’entrelacement, et si ces E/S sont aléatoires par nature, les requêtes d’E/S peuvent s’ajouter sur le même disque et provoquer un goulot d’étranglement responsable d’une dégradation des performances d’E/S.
Selon le type de charge de travail que votre application exécute, choisissez une taille d’entrelacement appropriée. Pour les petites requêtes d’E/S aléatoires, utilisez une plus petite taille d’entrelacement. Pour de grandes requêtes d’E/S séquentielles, utilisez une plus grande taille d’entrelacement. Recherchez les tailles d’entrelacement recommandées pour l’application que vous exécuterez sur du stockage Premium. Pour SQL Server, configurez une taille de frange de 64 Ko pour les charges de travail OLTP et de 256 Ko pour les charges de travail d’entreposage de données. Pour plus d’informations, consultez Meilleures pratiques relatives à SQL Server sur les machines virtuelles Azure.
Remarque
vous pouvez entrelacer au maximum 32 disques de stockage premium sur une machine virtuelle DS et 64 disques de stockage premium sur une machine virtuelle GS.
Multithreading
Azure a conçu la plateforme de stockage Premium de sorte qu’elle soit hautement parallèle. Ainsi, une application multithread délivre de meilleures performances qu’une application monothread. Une application multithread répartit ses tâches sur plusieurs threads, et augmente l’efficacité de son exécution en utilisant au maximum les ressources de machine virtuelle et de disque.
Par exemple, si votre application s’exécute sur une machine virtuelle monocœur utilisant deux threads, le processeur peut basculer entre les deux threads pour gagner en efficacité. En attendant l’exécution d’un thread sur une E/S de disque, le processeur peut basculer vers l’autre thread. De cette façon, deux threads peuvent accomplir bien plus qu’un seul thread. Si la machine virtuelle a plusieurs cœurs, elle réduit davantage le temps d’exécution car chaque cœur peut exécuter des tâches en parallèle.
Vous ne pourrez peut-être pas changer la façon dont une application du commerce implémente le monothreading ou le multithreading. Par exemple, SQL Server est capable de gérer plusieurs processeurs et plusieurs nœuds. SQL Server détermine cependant dans quelles conditions il utilise un ou plusieurs threads pour traiter une requête. Il peut exécuter des requêtes et créer des index à l’aide du multithreading. Dans le cas d’une requête impliquant une fusion de tables volumineuses et un tri des données avant le renvoi des résultats à l’utilisateur, SQL Server utilisera probablement plusieurs threads. Un utilisateur ne peut pas décider si SQL Server exécute une requête à l’aide d’un ou plusieurs threads.
Certains paramètres de configuration peuvent être modifiés de façon à influencer le multithreading ou le traitement parallèle d’une application. Par exemple, pour SQL Server, il s’agit de la configuration max degree of parallelism. Ce paramètre appelé MAXDOP permet de configurer le nombre maximal de processeurs que SQL Server peut utiliser lors du traitement parallèle. Vous pouvez configurer MAXDOP pour des requêtes individuelles ou pour des opérations d’index. Cette capacité est utile lorsque vous souhaitez équilibrer les ressources de votre système pour une application stratégique en termes de performances.
Supposez par exemple que votre application basée sur SQL Server exécute simultanément une requête volumineuse et une opération d’index. Imaginez que vous souhaitez que l’opération d’index soit plus performante que la requête volumineuse. Dans ce cas, vous pouvez spécifier une valeur MAXDOP de l’opération d’index supérieure à la valeur MAXDOP de la requête. SQL Server dispose ainsi d’un plus grand nombre de processeurs exploitables pour l’opération d’index, par rapport au nombre de processeurs qu’il peut consacrer à la requête volumineuse. N’oubliez pas que vous n’avez aucun contrôle sur le nombre de threads utilisés par SQL Server pour chaque opération. Vous pouvez contrôler le nombre maximal de processeurs dédiés au multithreading.
Apprenez-en davantage sur les degrés de parallélisme dans SQL Server. Découvrez comment ces paramètres influencent le multithreading dans votre application et leurs configurations pour optimiser les performances.
Profondeur de file d’attente
La profondeur, longueur ou taille de file d’attente correspond au nombre de requêtes d’E/S en attente dans le système. La valeur de profondeur de file d’attente détermine le nombre d’opérations d’E/S que votre application peut aligner et qui sont traitées par les disques de stockage. Elle affecte les trois indicateurs de performance abordés dans cet article, à savoir les IOPS, le débit et la latence.
La profondeur de file d’attente et le multithreading sont étroitement liés. La valeur de profondeur de file d’attente indique dans quelle mesure l’application peut prendre en charge le multithreading. Si la profondeur de file d’attente est importante, l’application peut exécuter davantage d’opérations simultanément, autrement dit davantage de multithreading. Si la profondeur de file d’attente est petite, même si l’application est de type multithread, le nombre de requêtes alignées sera insuffisant pour permettre une exécution simultanée.
En règle générale, les applications du commerce ne vous permettent pas de modifier la profondeur de la file d’attente, car un paramétrage incorrect peut faire plus de mal que de bien. Les applications définissent la valeur de la profondeur de file d’attente appropriée pour obtenir des performances optimales. Il est important de comprendre ce concept afin de pouvoir résoudre les problèmes de performances que vous pouvez rencontrer avec votre application. Vous pouvez également observer les effets de la profondeur de file d’attente en exécutant les outils de benchmarking sur votre système.
Certaines applications fournissent des paramètres qui influencent la profondeur de file d’attente. Par exemple, le paramètre MAXDOP dans SQL Server expliqué dans la section précédente. MAXDOP offre un moyen d’influencer la profondeur de file d’attente et le multithreading, sans pour autant modifier directement la valeur de profondeur de file d’attente de SQL Server.
Grande profondeur de file d’attente
Une grande profondeur de file d’attente permet d’aligner davantage d’opérations sur le disque. Le disque peut anticiper la prochaine demande placée dans sa file d’attente. Il peut ainsi planifier les opérations à l’avance et les traiter dans un ordre optimal. Étant donné que l’application envoie davantage de requêtes sur le disque, ce dernier peut traiter un plus grand nombre d’E/S parallèles. Au final, l’application est capable d’atteindre un taux supérieur d’IOPS. Puisque l’application traite davantage de requêtes, son débit total augmente également.
En général, une application peut atteindre un débit maximal avec entre huit et 16+ E/S en attente par disque connecté. Si la profondeur de file d’attente est égale à un, l’application n’envoie pas suffisamment d’E/S au système et en traite une plus petite quantité durant une période donnée. En d’autres termes, le débit sera moindre.
Par exemple, dans SQL Server, une valeur MAXDOP de 4 pour une requête indique à SQL Server qu’il peut utiliser jusqu’à quatre cœurs pour exécuter la requête. SQL Server détermine la meilleure valeur de profondeur de file d’attente ainsi que le nombre de cœurs à utiliser pour l’exécution de la requête.
Profondeur de file d’attente optimale
Une valeur de profondeur de file d’attente très élevée présente aussi des inconvénients. Si la valeur de profondeur de file d’attente est trop importante, l’application tente de générer un taux d’IOPS très élevé. À moins que l’application repose sur des disques persistants associés à un nombre suffisant d’IOPS, une valeur de profondeur de file d’attente très élevée peut affecter sérieusement les latences d’application. La formule suivante montre la relation entre les IOPS, la latence et la profondeur de file d’attente.
Vous ne devez pas configurer la profondeur de file d’attente sur une valeur élevée, mais plutôt sur une valeur optimale qui peut générer suffisamment d’IOPS pour l’application sans affecter les latences. Par exemple, si la latence de l’application doit être de une milliseconde, la profondeur de file d’attente requise pour atteindre 5 000 IOPS est la suivante : PF = 5 000 x 0,001 = 5.
Profondeur de file d’attente pour le volume entrelacé
Pour un volume entrelacé, conservez une profondeur de file d’attente suffisamment élevée de sorte que chaque disque dispose individuellement d’un pic de profondeur de file d’attente. Prenez l’exemple d’une application qui envoie (push) une profondeur de file d’attente de 2 dans un scénario d’entrelacement à quatre disques. Les deux requêtes d’E/S sont transmises à deux disques et les deux disques restants sont inactifs. Vous devez par conséquent configurer la profondeur de file d’attente afin que tous les disques puissent être occupés. La formule suivante montre comment déterminer la profondeur de file d’attente des volumes entrelacés.
Limitation
Le stockage Premium provisionne une valeur spécifiée d’IOPS et de débit en fonction des tailles de machine virtuelle et des tailles de disque que vous choisissez. Chaque fois que votre application tente de dépasser les limites d’IOPS et de débit gérables par la machine virtuelle ou le disque, le stockage Premium lui impose une limitation. Le résultat est une dégradation des performances dans votre application, ce qui peut signifier une latence plus élevée, un débit inférieur ou des IOPS inférieures.
Sans cette limitation du stockage Premium, votre application risquerait de planter en demandant davantage que ses ressources ne lui permettent d’effectuer. Pour éviter les problèmes de performances associés à une limitation, veillez à toujours provisionner suffisamment de ressources pour votre application. Tenez compte des explications données dans les sections précédentes relatives aux tailles de disque et aux tailles de machine virtuelle. Le benchmarking offre le meilleur moyen de déterminer les ressources dont vous avez besoin pour héberger votre application.
Étapes suivantes
Si vous souhaitez évaluer votre disque, consultez les articles suivants :
- Pour Linux : Créer un benchmark de votre application sur Stockage sur disque Azure
- Pour Windows : Évaluer un disque
En savoir plus sur les types de disque disponibles :
- Pour Linux : Sélectionner un type de disque
- Pour Windows : Sélectionner un type de disque
Pour les utilisateurs de SQL Server, consultez les articles relatifs aux bonnes pratiques de performances de SQL Server :