Partager via

Optimiser les performances sur les machines virtuelles Linux de série Lsv3, Lasv3 et Lsv2

  • Article

Attention

Cet article fait référence à CentOS, une distribution Linux ayant atteint l’état EOL (fin du service). Faites le point sur votre utilisation et organisez-vous en conséquence. Pour plus d’informations, consultez les conseils d’aide relatifs à la fin de vie de CentOS.

S’applique à : ✔️ Machines virtuelles Linux ✔️ Groupes identiques uniformes

Les machines virtuelles Azure de série Lsv3, Lasv3 et Lsv2 prennent en charge diverses charges de travail qui nécessitant des E/S et des débits élevés au niveau du stockage local pour un large éventail d’applications et de secteurs d’activité. La série L est idéale pour le Big Data, SQL, les bases de données NoSQL, l’entreposage de données et les bases de données transactionnelles volumineuses, notamment Cassandra, MongoDB, Cloudera et Redis.

Plusieurs builds sont disponibles sur la Place de marché Azure en raison de la collaboration avec des partenaires dans Linux. Ces builds sont optimisées pour les performances des séries Lsv3, Lasv3 et Lsv2. Les builds disponibles incluent les versions suivantes et ultérieures de :

  • Ubuntu 16.04
  • RHEL 8.0 et clones, y compris CentOS, Rocky Linux et Alma Linux
  • Debian 9
  • SUSE Linux 15
  • Oracle Linux 8.0

Cet article fournit des conseils et des suggestions pour faire en sorte que vos charges de travail et vos applications atteignent les performances maximales dans les machines virtuelles.

Architecture du circuit microprogrammé AMD EPYC™

Les machines virtuelles de série Lasv3 et Lsv2 utilisent des processeurs serveur AMD EPYC™ basés sur la micro-architecture Zen. AMD a développé Infinity Fabric (IF) pour EPYC™ en tant qu’interconnexion scalable pour son modèle NUMA qui peut être utilisé pour les communications au niveau du die, du package et entre plusieurs packages. Par rapport à QPI (Quick-Path Interconnect) et à UPI (Ultra-Path Interconnect), tous deux utilisés sur les processeurs modernes Intel à dies monolithiques, l’architecture AMD constituée de nombreux dies de petite taille NUMA peut offrir des avantages sur le plan des performances, mais créer aussi des difficultés. Les effets réels des contraintes de bande passante et de latence de la mémoire peuvent varier en fonction du type des charges de travail exécutées.

Conseils pour optimiser les performances

  • Si vous chargez un système d’exploitation invité Linux personnalisé pour votre charge de travail, l’accélération réseau est désactivée par défaut. Si vous avez l’intention d’activer la mise en réseau accélérée, pour bénéficier de performances optimales, faites-le pendant la création de machines virtuelles.
  • Pour obtenir des performances maximales, exécutez plusieurs travaux avec une profondeur de file d’attente élevée par appareil.
  • Évitez de combiner des commandes d’administration NVMe (par exemple, une requête d’information NVMe SMART, etc.) avec des commandes d’E/S NVMe pendant que des charges de travail sont actives. Les appareils NVMe Lsv3, Lasv3 et Lsv2 reposent sur la technologie Hyper-V NVMe Direct, qui passe en « mode lent » chaque fois que des commandes d’administration NVMe sont en attente. Dans ce cas, les utilisateurs Lsv3, Lasv3 et Lsv2 risquent d’observer une baisse considérable des performances des E/S NVMe.
  • Pour définir l’affinité NUMA de leurs applications, il est déconseillé aux utilisateurs Lsv2 de se fier aux informations NUMA des appareils présentées dans les machines virtuelles pour les lecteurs de données (valeurs 0). Pour de meilleures performances, il est recommandé de répartir les charges de travail entre les UC, dans la mesure du possible.
  • La profondeur de file d’attente maximale prise en charge par paire de files d’attente d’E/S pour les appareils NVMe de machines virtuelles Lsv3, Lasv3 et Lsv2 est de 1024. Nous conseillons aux utilisateurs Lsv3, Lasv3 et Lsv2 de limiter leurs charges de travail de benchmarking (synthétique) à une profondeur de file d’attente de 1024 ou moins pour éviter de déclencher des conditions de file d’attente saturée, susceptibles de faire baisser les performances.
  • Les meilleures performances sont obtenues quand les E/S se produisent directement au niveau de chaque appareil NVMe brut sans aucun partitionnement, aucun système de fichiers, aucune configuration RAID, etc. Avant de démarrer une session de test, vérifiez que la configuration se trouve dans un état nouveau/propre connu en exécutant blkdiscard sur chaque appareil NVMe. Pour obtenir les performances les plus constantes lors de l’évaluation, il est recommandé de préconditionner les appareils NVMe, avant de les tester en émettant deux fois des écritures aléatoires sur les LBA de tous les appareils, comme défini dans la spécification de test de performance du SNIA Solid State Storage Enterprise.

Utilisation du stockage NVMe local

Le stockage local sur le disque NVMe de 1,92 To est éphémère pour toutes les machines virtuelles Lsv3, Lasv3 et Lsv2. Lors d’un redémarrage standard réussi de la machine virtuelle, les données présentes sur le disque NVMe local sont conservées. Les données ne sont pas conservées sur le NVMe si la machine virtuelle est redéployée, désallouée ou supprimée. Les données ne sont pas conservées si la machine virtuelle ou le matériel sur lequel elle s’exécute n’est pas sain à cause d’un autre problème. Dans ce scénario, toutes les données présentes sur l’ancien hôte sont effacées de manière sécurisée.

Dans certains cas, il peut aussi être nécessaire de déplacer la machine virtuelle sur une autre machine hôte, par exemple à l’occasion d’une opération de maintenance planifiée. Les opérations de maintenance planifiée et certaines défaillances matérielles peuvent être anticipées avec Scheduled Events. Utilisez Scheduled Events pour rester informé des opérations de maintenance et de récupération prévues.

Si un événement de maintenance planifiée exige la récréation de la machine virtuelle sur un nouvel hôte avec des disques locaux vides, les données doivent être resynchronisées (là encore, les données présentes sur l’ancien hôte seront effacées de manière sécurisée). Ce scénario s’explique par le fait que les machines virtuelles de série Lsv3, Lasv3 et Lsv2 ne prennent pas actuellement en charge la migration dynamique sur le disque NVMe local.

Il existe deux modes de maintenance planifiée.

Maintenance standard contrôlée par le client de la machine virtuelle

  • La machine virtuelle est déplacée sur un hôte mis à jour sur une fenêtre de 30 jours.
  • Le risque de perte de données sur le stockage local Lsv3, Lasv3 et Lsv2 n’étant pas à écarter, il est recommandé de sauvegarder les données avant l’événement.

Maintenance automatique

  • Intervient en l’absence de maintenance contrôlée par le client ou en cas de procédure d’urgence, par exemple à la suite d’un événement de sécurité zero-day.
  • Destinée à préserver les données client, la machine virtuelle présente un léger risque de blocage ou de redémarrage.
  • Le risque de perte de données sur le stockage local Lsv3, Lasv3 et Lsv2 n’étant pas à écarter, il est recommandé de sauvegarder les données avant l’événement.

Pour les événements de maintenance à venir, utilisez le processus de maintenance contrôlée afin de sélectionner le moment le plus opportun pour effectuer la mise à jour. Avant l’événement, sauvegardez vos données sur un stockage premium. À l’issue de l’événement de maintenance, vous pouvez renvoyer vos données vers le stockage NVMe local des machines virtuelles Lsv3, Lasv3 et Lsv2 actualisées.

Voici quelques scénarios où les données sont conservées sur les disques NVMe locaux :

  • La machine virtuelle est en cours d’exécution et saine.
  • La machine virtuelle est redémarrée sur place (par vous ou Azure).
  • La machine virtuelle est mise en pause (arrêtée sans désallocation).
  • La plupart des opérations de maintenance planifiée.

Voici quelques scénarios où les données du client sont effacées par mesure de sécurité :

  • La machine virtuelle est redéployée, arrêtée (désallouée) ou supprimée (par vous).
  • L’état de la machine virtuelle devient non sain et le service doit être réparé sur un autre nœud en raison d’un problème matériel.
  • Quelques opérations de maintenance planifiée qui nécessitent la réallocation de la machine virtuelle vers un autre hôte à des fins de maintenance.

Forum aux questions

Voici une liste de questions fréquentes concernant ces séries.

Comment lancer le déploiement de machines virtuelles de la série L ?

Comme n’importe quelle autre machine virtuelle, utilisez le portail, Azure CLI ou PowerShell pour créer une machine virtuelle.

La défaillance d’un disque NVMe unique peut-elle entraîner la défaillance de toutes les machines virtuelles présentes sur l’hôte ?

Si une défaillance de disque est détectée sur le nœud matériel, le matériel est à l’état d’échec. Quand ce problème se produit, toutes les machines virtuelles du nœud sont automatiquement désallouées et déplacées vers un nœud sain. Pour les machines virtuelles de série Lsv3, Lasv3 et Lsv2, ce problème signifie que les données du client sur le nœud défaillant sont également effacées de manière sécurisée. Le client doit recréer les données sur le nouveau nœud.

Ai-je besoin de modifier les paramètres blk_mq ?

RHEL/CentOS 7.x utilise automatiquement blk-mq pour les appareils NVMe. Il n’est pas utile de modifier la configuration ou des paramètres.

Étapes suivantes

Consultez les spécifications pour toutes les machines virtuelles à stockage optimisé sur Azure