Partager via

FAQ sur les performances d’Azure NetApp Files

  • Article

Cet article contient les réponses à certaines questions fréquemment posées sur les performances d’Azure NetApp Files.

Que puis-je faire pour optimiser ou ajuster les performances d’Azure NetApp Files ?

Vous pouvez effectuer les actions suivantes en fonction de vos exigences en matière de performances :

  • Vérifiez que la machine virtuelle est dimensionnée de manière appropriée.
  • Activez les performances réseau accélérées pour la machine virtuelle.
  • Sélectionnez le niveau de service et la taille voulus pour le pool de capacités.
  • Créez un volume avec la taille de quota de votre choix pour la capacité et les performances.

Il n’est pas nécessaire de définir la mise en réseau accélérée pour les cartes d’interface réseau dans le sous-réseau dédié d’Azure NetApp Files. La mise en réseau accélérée est une fonctionnalité qui s’applique uniquement aux machines virtuelles Azure. Les cartes réseau Azure NetApp Files sont déjà optimisées par leur conception.

Comment surveiller les performances du volume Azure NetApp Files

Les performances des volumes Azure NetApp Files peuvent être surveillées via métriques disponibles.

Comment convertir les niveaux de service basés sur le débit d’Azure NetApp Files en opérations d’entrée/sortie par seconde (IOPS) ?

Vous pouvez convertir des mégaoctets par seconde (Mbits/s) en IOPS avec cette formule :

IOPS = (MBps Throughput / KB per IO) * 1024

Comment modifier le niveau de service d’un volume ?

Vous pouvez modifier le niveau de service d’un volume existant en déplaçant le volume vers un autre pool de capacité qui utilise le niveau de service souhaité pour le volume. Consultez Changer dynamiquement le niveau de service d’un volume.

Comment surveiller les performances d’Azure NetApp Files ?

Azure NetApp Files fournit des métriques de performance des volumes. Vous pouvez également utiliser Azure Monitor pour surveiller les métriques d’utilisation pour Azure NetApp Files. Consultez Métriques pour Azure NetApp Files pour obtenir la liste des métriques de performance pour Azure NetApp Files.

Pourquoi la latence d’une charge de travail est-elle élevée alors que le nombre d’IOPS est faible ?

En l’absence d’autres symptômes (tels que des erreurs, des problèmes réseau ou une application qui ne répond pas), les charges de travail présentant un faible nombre d’IOPS ne sont généralement pas un problème. On considère généralement que le nombre d’IOPS est faible quand il se situe en dessous de 500 à 600 IOPS, mais cela peut varier.

Azure NetApp Files répond aux demandes à mesure qu’elles se présentent. Une charge de travail présentant peu de demandes peut apparaître plus élevée, mais elle répond comme prévu. Les caractéristiques des charges de travail ayant un faible nombre d’IOPS (par exemple, 5 IOPS et 32 Kio/s) sont les suivantes :

  • Elles ne se trouvent pas dans le cache RAM, ce qui demande plus d’accès au disque.
  • Elles n’ont pas une taille d’échantillon élevée, ce qui signifie que du point de vue statistique, elles ne présentent aucun intérêt.
  • Le nombre d’échantillons dont elles disposent n’est pas suffisant pour lisser les valeurs hors norme.

La latence signalée peut se compter en secondes voire en dizaines de secondes du fait du calcul biaisé de la latence moyenne. En faisant croître la charge de travail sur le volume présentant un faible nombre d’IOPS, cela peut aider à déterminer si le biais de latence est ce qui explique que la valeur de latence est excessive.

Quel est l’impact sur les performances de Kerberos sur NFSv4.1 ?

Pour plus d’informations sur les options de sécurité pour NFSv4.1, les vecteurs de performances testés et l’impact sur les performances attendu, consultez Impact de Kerberos sur les performances des volumes NFSv4.1.

Quel est l’impact sur les performances d’utiliser nconnect avec Kerberos ?

Il n’est pas recommandé d’utiliser les options de montage nconnect et sec=krb5* ensemble. La détérioration des performances a été observée lors de l’utilisation des deux options combinées.

L’interface de programmation d’applications standard de sécurité générique (GSS-API) permet aux applications de protéger les données envoyées aux applications homologues. Ces données peuvent être envoyées d’un client sur un ordinateur à un serveur sur un autre ordinateur. 

Lorsque nconnect est utilisé dans Linux, le contexte de sécurité GSS est partagé entre toutes les connexions nconnect à un serveur particulier. TCP est un transport fiable qui prend en charge la livraison de paquets non ordonnés pour traiter les paquets non ordonnés dans un flux GSS, à l’aide d’une fenêtre glissante de numéros de séquence. Lorsque les paquets non dans la fenêtre de séquence sont reçus, le contexte de sécurité est ignoré et un nouveau contexte de sécurité est négocié. Tous les messages envoyés dans le contexte maintenant ignoré ne sont plus valides, ce qui oblige les messages à être renvoyés. Un plus grand nombre de paquets dans une configuration nconnect provoque des paquets non dans la fenêtre fréquents, ce qui déclenche le comportement décrit. Aucun pourcentage de détérioration spécifique ne peut être indiqué avec ce comportement.

Azure NetApp Files prend-il en charge SMB Direct ?

Non, Azure NetApp Files ne prend pas en charge SMB Direct.

L’association de cartes réseau est-elle prise en charge dans Azure ?

L’association de cartes réseau n’est pas prise en charge dans Azure. Bien que plusieurs interfaces réseau soient prises en charge sur les machines virtuelles Azure, elles représentent une construction logique plutôt qu’une construction physique. Ainsi, elles ne fournissent aucune tolérance de panne. En outre, la bande passante disponible pour une machine virtuelle Azure est calculée pour la machine elle-même, et non pour une interface réseau individuelle.

Les trames Jumbo sont-elles prises en charge ?

Les trames Jumbo ne sont pas prises en charge avec les machines virtuelles Azure.

Étapes suivantes