🥇Analyse des performances des VM dans VMware vSphere. Partie 3 : Stockage

Partie 1. Sur le CPU
Partie 2. Sur la mémoire

Aujourd'hui, nous allons examiner les métriques du système de stockage dans vSphere. Un problème de stockage est la cause la plus fréquente du ralentissement des machines virtuelles. Contrairement aux problèmes liés au CPU et à la RAM, dont le dépannage s'arrête généralement au niveau de l'hyperviseur, les problèmes de disque peuvent nécessiter une investigation au niveau du réseau de stockage et du SAN.

Je vais aborder le sujet en prenant comme exemple l'accès par blocs au SAN, bien que les compteurs soient à peu près les mêmes pour l'accès par fichiers.

Un peu de théorie

Lorsqu'on parle de performance des systèmes de stockage des machines virtuelles, on fait généralement attention à trois paramètres interconnectés :

le nombre d'opérations d'entrée/sortie (Input/Output Operations Per Second, IOPS);
la bande passante (Throughput);
la latence des opérations d'entrée/sortie (Latency).

Le nombre d'IOPS est généralement important pour les charges de travail de nature aléatoire : accès à des blocs sur le disque situés à différents endroits. Un exemple de ce type de charge peut être constitué par des bases de données, des applications métier (ERP, CRM), etc.

Bande passante est crucial pour les charges de travail de nature séquentielle : accès à des blocs situés les uns à la suite des autres. Par exemple, une telle charge peut être générée par des serveurs de fichiers (mais pas toujours) et des systèmes de vidéosurveillance.

La bande passante est liée au nombre d'opérations d'entrée/sortie de la manière suivante :

Throughput = IOPS * Taille de bloc, où Taille de bloc est la taille du bloc.

La taille du bloc est une caractéristique assez importante. Les versions modernes d'ESXi prennent en charge des blocs jusqu'à 32 767 Ko. Si le bloc est plus grand, il est divisé en plusieurs. Tous les SAN ne peuvent pas fonctionner efficacement avec de si grands blocs, c'est pourquoi dans les paramètres avancés d'ESXi, il existe un paramètre DiskMaxIOSize. Ce dernier permet de réduire la taille de bloc maximale que l'hyperviseur peut traiter (voir plus en détail ici). Je recommande de consulter le fabricant du SAN avant de modifier ce paramètre ou, au moins, de tester les changements sur un banc d'essai.

Une trop grande taille de bloc peut nuire à la performance du SAN. Même si le nombre d'IOPS et la bande passante sont relativement faibles, des latences élevées peuvent être observées avec une grande taille de bloc. Par conséquent, il est essentiel de surveiller ce paramètre.

Latence – le paramètre de performance le plus intéressant. La latence des opérations d'entrée/sortie pour une machine virtuelle est composée de :

la latence à l'intérieur de l'hyperviseur (KAVG, Average Kernel MilliSec/Read);
les délais causés par le réseau de données et le SAN (DAVG, Millisecondes Moyennes du Pilote / Commande).

Le délai global visible dans le système d'exploitation invité (GAVG, Millisecondes Moyennes Invitées / Commande) est la somme de KAVG et DAVG.

GAVG et DAVG sont mesurés, tandis que KAVG est calculé : GAVG - DAVG.

Source

Approfondissons KAVG. En fonctionnement normal, KAVG doit tendre vers zéro ou, du moins, être bien inférieur à DAVG. Le seul cas que je connaisse où KAVG est exceptionnellement élevé est la limitation d'IOPS sur le disque de la VM. Dans ce cas, lorsque la limite est dépassée, KAVG augmente.

La composante la plus significative de KAVG est QAVG – le temps d'attente pour traitement à l'intérieur de l'hyperviseur. Les autres composantes de KAVG sont négligeables.

Les files d'attente dans le pilote de l'adaptateur de disque et les files d'attente vers les LUN ont une taille fixe. Pour les environnements très chargés, il peut être utile d'augmenter cette taille. Ici décrit comment augmenter les files d'attente dans le pilote de l'adaptateur (la file vers les LUN augmentera également). Ce paramètre fonctionne lorsque seule une VM opère sur la LUN, ce qui est rare. Si plusieurs VMs sont sur la LUN, il est également nécessaire d'augmenter le paramètre Disk.SchedNumReqOutstanding (instruction ici). En augmentant la file d'attente, vous réduisez respectivement QAVG et KAVG.

Mais encore une fois, consultez d'abord la documentation du fournisseur HBA et testez les modifications sur un banc d'essai.

La taille de la file d'attente vers la LUN peut être influencée par l'activation du mécanisme SIOC (Storage I/O Control). Il assure un accès équilibré à la LUN de la part de tous les serveurs du cluster en modifiant dynamiquement la file d'attente vers la LUN sur les serveurs. Ainsi, si une VM sur l'un des hôtes nécessite des performances disproportionnées (VM bruyante), SIOC réduit la longueur de la file d'attente vers la LUN sur cet hôte (DQLEN). Pour en savoir plus, ici.

Nous avons compris KAVG, maintenant parlons un peu de DAVG. C'est simple : DAVG est le délai introduit par l'environnement externe (réseau de données et SAN). Dans tout SAN moderne, il existe des compteurs de performance. Pour analyser les problèmes de DAVG, il est judicieux de les surveiller. Si tout va bien du côté d'ESXi et du SAN, vérifiez le réseau de données.

Pour éviter les problèmes de performance, choisissez la bonne Politique de Sélection de Chemin (PSP) pour votre stockage. Pratiquement tous les systèmes de stockage modernes prennent en charge la politique PSP Round-Robin (avec ALUA, Accès Logique Asymétrique aux Unités, ou sans). Cette politique permet d'utiliser tous les chemins disponibles vers le stockage. Dans le cas d'ALUA, seuls les chemins menant au contrôleur qui possède le LUN sont utilisés. Il ne existe pas de règles par défaut indiquant la politique Round-Robin pour tous les systèmes de stockage sur ESXi. Si aucune règle n'existe pour votre stockage, utilisez le plugin du fabricant du stockage qui créera la règle appropriée sur tous les hôtes du cluster, ou créez la règle vous-même. Pour plus de détails. ici.

De plus, certains fabricants de stockage recommandent de modifier le nombre d'IOPS par chemin de la valeur standard de 1000 à 1. Dans notre expérience, cela a permis de « tirer » plus de performance du stockage et de réduire considérablement le temps nécessaire au basculement en cas de défaillance ou de mise à jour des contrôleurs. Vérifiez les recommandations du fournisseur, et s'il n'y a pas de contre-indications, essayez de modifier ce paramètre. Pour plus de détails. ici.

Les principaux compteurs de performance du sous-système de disque de la machine virtuelle.

Les compteurs de performance du sous-système de disque dans vCenter sont rassemblés dans les sections Datastore, Disk, Virtual Disk :

Dans la section Datastore contiennent des métriques sur les stockages de disques vSphere (datastores) sur lesquels se trouvent les disques des VM. Ici, vous trouverez les compteurs standards pour :

les IOPS (Requêtes de lecture/écriture par seconde en moyenne),
la bande passante (Taux de lecture/écriture),
les latences (Latence maximale de lecture/écriture).

D'après les noms des compteurs, tout est en principe clair. Je souligne encore une fois que ces statistiques ne concernent pas une VM spécifique (ou un disque de VM), mais sont générales pour tout le datastore. À mon avis, il est plus pratique de consulter ces statistiques dans ESXTOP, ne serait-ce que parce que la période minimale de mesure y est de 2 secondes.

Dans la section Disque contiennent des métriques sur les dispositifs de blocs utilisés par les VM. Ici, il y a des compteurs d'IOPS de type sommation (nombre d'opérations d'entrée/sortie sur la période de mesure) et plusieurs compteurs relatifs à l'accès block (Commandes annulées, Réinitialisations de bus). À mon avis, il est également plus pratique de consulter ces informations dans ESXTOP.

Section Disque Virtuel Le plus utile pour diagnostiquer les problèmes de performance du sous-système de disques de la VM. Ici, vous pouvez consulter les performances de chaque disque virtuel. Cette information est nécessaire pour déterminer s'il existe un problème avec une machine virtuelle spécifique. En plus des compteurs standard que sont le nombre d'opérations d'entrée/sortie, le volume de lecture/écriture et les latences, cette section présente des compteurs utiles qui montrent la taille de bloc : taille de demande de lecture/écriture.

Dans l'image ci-dessous, le graphique de performance du disque de la VM, où vous pouvez voir le nombre d'IOPS, les latences et la taille de bloc.

Les métriques de performance peuvent également être consultées sur l'ensemble du datastore, si SIOC est activé. Voici des informations de base sur la latence moyenne et les IOPS. Par défaut, ces informations ne peuvent être consultées qu'en temps réel.

ESXTOP

Dans ESXTOP, il y a plusieurs écrans qui présentent des informations sur le sous-système de disques de l'hôte dans son ensemble, pour des machines virtuelles spécifiques et leurs disques.

Commençons par les informations sur les machines virtuelles. L'écran "Disk VM" s'affiche en appuyant sur la touche "v" :

NVDISK – c'est le nombre de disques VM. Pour consulter les informations de chaque disque, appuyez sur "e" et entrez le GID de la VM qui vous intéresse.

La valeur des autres paramètres sur cet écran est claire à partir de leurs noms.

Un autre écran utile pour la recherche de problèmes est l'adaptateur de disque. Il s'affiche en appuyant sur la touche "d" (dans l'image ci-dessous, les champs A, B, C, D, E, G sont sélectionnés) :

NPTH – le nombre de chemins vers les LUNs visibles depuis cet adaptateur. Pour obtenir des informations sur chaque chemin de l'adaptateur, appuyez sur "e" et entrez le nom de l'adaptateur :

AQLEN – la taille maximale de la file d'attente sur l'adaptateur.

Cette écran affiche également les compteurs de latence, dont j'ai parlé ci-dessus : KAVG/cmd, GAVG/cmd, DAVG/cmd, QAVG/cmd.

Sur l'écran Disque device, accessible en appuyant sur la touche "u", des informations sur des dispositifs de bloc séparés – les LUNs (dans l'image ci-dessous, les champs A, B, F, G, I sont sélectionnés). Ici, vous pouvez voir l'état de la file d'attente vers les LUNs.

DQLEN – la taille de la file d'attente pour le dispositif de bloc.
ACTV – le nombre de commandes d'entrée/sortie dans le noyau ESXi.
QUED – le nombre de commandes d'entrée/sortie dans la file d'attente.
%USD – ACTV / DQLEN × 100%.
LOAD – (ACTV + QUED) / DQLEN.

Si %USD est élevé, il vaut la peine d'envisager d'augmenter la file d'attente. Plus il y a de commandes dans la file, plus le QAVG est élevé et, par conséquent, le KAVG.

Sur l'écran du périphérique disque, vous pouvez également voir si VAAI (vStorage API for Array Integration) fonctionne sur le stockage SAN. Pour cela, il faut sélectionner les champs A et O.

Le mécanisme VAAI permet de décharger une partie du travail de l'hyperviseur directement sur le stockage SAN, par exemple, la mise à zéro, la copie des blocs ou les verrous.

Comme on peut le voir sur l'image ci-dessus, VAAI est actif sur ce stockage SAN : les primitives Zero et ATS sont utilisées activement.