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

  • Article

S’applique aux : ✔️ Machines virtuelles Windows ✔️ 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.

Les machines virtuelles de série Lsv3, Lasv3 et Lsv2 sont conçues pour répondre aux besoins des systèmes d’exploitation Windows et Linux afin d’offrir de meilleures performances sur le plan matériel et logiciel.

Les réglages apportés aux logiciels et au matériel ont abouti à la version optimisée de Windows Server 2019 Datacenter, qui a été publiée sur la Place de marché Azure ( et versions ultérieures), qui autorise des performances maximales sur les appareils NVMe des machines virtuelles de la série L.

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.

Conseils pour optimiser les performances

  • 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) 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. Si ce scénario se produit, 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 processeurs, 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.

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 : la maintenance standard contrôlée par le client de la machine virtuelle et la maintenance automatique.

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, renvoyez vos données vers le stockage NVMe local des machines virtuelles 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.

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

Dans la maintenance standard contrôlée par le client de la machine virtuelle, la machine virtuelle est déplacée vers un hôte mis à jour pendant 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

La maintenance automatique intervient en l’absence de maintenance contrôlée par le client. La maintenance automatique peut également se produire en raison de procédures d’urgence, telles qu’un événement de sécurité zero-day.

Ce type de maintenance est destiné à préserver les données client, mais 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.

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 ?

Tout comme n’importe quelle autre machine virtuelle, créez une machine virtuelle à l’aide du portail Azure, via l’interface de ligne de commande Azure (Azure CLI) ou via PowerShell.

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 scénario 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.

Dois-je effectuer des réglages d’interrogation sur Windows Server 2012 ou Windows Server 2016 ?

L’interrogation NVMe n’est disponible que sur Windows Server 2019 et versions ultérieures sur Azure.

Puis-je revenir à un modèle traditionnel de routine d’interruption de service (RSI) ?

Les machines virtuelles de série Lasv3 et Lsv2 sont optimisées pour l’interrogation NVMe. Des mises à jour sont fournies en permanence afin d’améliorer la performance des interrogations.

Puis-je régler les paramètres d’interrogation dans Windows Server 2019 ou versions ultérieures ?

Les utilisateurs ne peuvent pas régler les paramètres d’interrogation.

Étapes suivantes

Consultez les spécifications pour toutes les machines virtuelles optimisées pour les performances de stockage sur Azure.