Serveur d'impression

Accélérations synthétiques en bref – Windows Server 2012 – Communauté Microsoft Tech – Bien choisir son serveur d impression

Par Titanfall , le 16 octobre 2019 - 19 minutes de lecture

Salut les gens,

Dan Cuomo ici pour parler de l'état des accélérations synthétiques (parfois même avec VMQ) sur Windows Server. Il s'agit du premier d'une série d'articles traitant des accélérations synthétiques des années 2012, 2012 R2, 2016 et 2019. Nous vous recommandons de suivre la progression des articles (une fois disponibles) pour vous assurer de disposer des informations appropriées pour chaque système d'exploitation que vous utilisez. êtes la gestion.

Certaines choses ne changent jamais. Ils sont ce qu'ils sont. Pour toujours.

a.png

Le ciel sera toujours bleu (à moins que vous ne soyez à Seattle), il restera toujours 60 secondes par minute (à moins d’une seconde intercalaire)… ok, certaines choses changent. Et en raison de la règle littéraire de trois, la technologie évolue également.

Les files d'attente de machines virtuelles (VMQ) ne font pas exception. Cette technologie a été introduite pour la première fois dans Windows Server 2012 afin de répartir le traitement des paquets réseau reçus destinés à une carte réseau virtuelle sur différents cœurs. Une fois que les adaptateurs 10 GbE sont devenus répandus, le traitement du réseau a rapidement consommé plus qu'un seul cœur ne pouvait gérer. La première chose que la plupart des gens font après avoir acheté leur nouvel adaptateur 10 GbE est d'essayer de copier quelque chose sur le réseau pour voir la vitesse extrêmement rapide. Tous avaient l'air super, 9 + Gbps! Donc, vous ajoutez quelques machines virtuelles et répétez l'expérience. À votre grand regret, vous obtenez un débit décevant de 3 à 5 Gbps. Qu'est-il arrivé? Hyper-V doit avoir une régression !?

Non, c’est simplement que vous êtes en train d’assembler un seul cœur de processeur. ** Entrez VMQ **

J’ai vu beaucoup de blogs sur la bonne façon de le cingler, de le stimuler et de transformer VMQ en soumission à demi volontaire. Les versions de Windows Server sont arrivées et ont évolué considérablement, car elles appliquent les meilleures pratiques pour VMQ. Dans cette série de blogs, nous allons donc essayer de dissiper les mythes et de donner les détails nécessaires pour le configurer correctement dans chacune des versions disponibles sur le marché, en commençant par la publication d'aujourd'hui sur Windows Server 2012. Nous aborderons également certaines des modifications clés apportées en 2012 R2, 2016 et 2019 pour vous permettre de comprendre comment configurer votre système si vous utilisez l'un de ces systèmes d'exploitation.

Mais d'abord, quelques antécédents…

Tout d'abord, vous avez peut-être remarqué que ce blog ne s'intitule pas VMQ Deep Dive 1, 2 ou 3 – Ces articles précédemment publiés étaient des ressources impressionnantes à leur époque (en fait, j'emprunte une partie du contenu original pour ces articles). . Mais avec le temps qui passe et (coïncidant avec notre migration vers le nouveau site de blogs), il est nécessaire de définir un contexte approprié pour les systèmes d’exploitation disponibles du jour.

VMQ était une fonction indépendante du système d’exploitation et, à ce titre, elle est devenue synonyme d’accélération du réseau sur Hyper-V. Ce n'est plus le cas, comme vous le verrez dans les sections sur Windows Server 2016 et 2019. En fait, nous appelons maintenant la VMQ décrite dans cet article «Legacy VMQ» (par rapport à la VMQ basée sur vPort, qui sera expliquée plus loin). Articles 2016 et 2019).

Crédit où le crédit est dû. Les articles originaux qui sont remplacés / mis à jour ici sont:

  • Gabe Silva – VMQ Deep Dive, 1 sur 3
  • Gabe Silva – VMQ Deep Dive, 2 sur 3
  • Gabe Silva – VMQ Deep Dive, 3 sur 3
  • Marco Cancillo – Trucs et astuces sur l'affectation de l'UC de la machine virtuelle (VMQ)

En outre, ce blog porte un tel titre en fonction du chemin de données que les paquets traversent le système pour atteindre leur destination, une carte réseau virtuelle dans l'hôte ou un invité.

Alors, qu'entendons-nous par le chemin de données «synthétique»? Cela signifie que le trafic passe par le commutateur virtuel. À un niveau élevé, le chemin de données ressemble à ceci:

b.png

Les paquets sont acheminés du réseau vers le NIC et le miniport par le fournisseur du NIC. Le commutateur virtuel traite les paquets et envoie les données à parcourir sur le vmBus avant d'atteindre le vmNIC et d'être traitées par la pile de réseaux de la machine virtuelle. C'est le chemin de données le plus courant pour la communication réseau dans Hyper-V et, comme vous pouvez le constater, les paquets transitent par le commutateur virtuel, ce qui nécessite l'utilisation de cœurs de processeur physiques.

Remarque: Ceci ne s'applique pas à RDMA ou à d'autres technologies d'accès direct à la mémoire telles que SR-IOV.

Voyons maintenant l’architecture de la carte réseau et son interopérabilité avec la famille de systèmes d’exploitation 2012.

Chaque flux de paquets entrant dans une carte réseau se voit attribuer une file d'attente matérielle, que vous utilisiez Hyper-V ou non. La manière dont l'adaptateur filtre les paquets dépend de si vous avez un commutateur virtuel connecté à cet adaptateur.

Par exemple, si vous avez un adaptateur sans Hyper-V connecté, la carte réseau calcule un hachage pour distribuer les paquets à différentes files d'attente de la carte réseau. Le pilote de miniport peut interrompre ou DPC sur les cœurs de la CPU pour qu'une CPU traite les paquets entrants. Voici comment fonctionne le RSS.

Remarque: Chaque file d'attente est une paire de files d'attente; un envoi, un recevoir. Les files d'attente ci-dessous sont désignées par «QP» ou paire de files d'attente.

c.png

Cependant, lorsque vous avez un commutateur virtuel connecté, la carte réseau crée un filtre basé sur chaque combinaison MAC et VLAN de vmNIC sur le commutateur virtuel Hyper-V (vSwitch). Lorsqu'un paquet arrive dans ce contexte, un filtre est appliqué pour vérifier si le paquet correspond à l'une des combinaisons MAC et VLAN déjà vues. s'il y a correspondance, le paquet est envoyé à la file d'attente correspondante qui a été affectée à ce filtre de paquets. S'il n'y a pas de correspondance, il est envoyé à la file d'attente par défaut – Il y a toujours une file d'attente par défaut.

d.png

De cette façon, RSS était fonctionnellement désactivé (pour cet adaptateur) au moment où vous avez connecté un vSwitch. Indépendamment de ce que vous voyez dans Get-NetAdapterRSS, RSS n’est pas utilisé avec cette version du système d’exploitation. En raison de certains problèmes de support, notamment avec les pilotes de carte réseau au tout début de VMQ, il a été recommandé de désactiver manuellement RSS lorsque VMQ est activé sur le système.

Nous ne prenons pas en charge la désactivation de RSS pour aucun système d'exploitation pour plusieurs raisons:

  • La désactivation de RSS le désactive pour chaque adaptateur. Tout adaptateur non connecté au commutateur virtuel peut toujours utiliser RSS et, en tant que tel, serait affecté négativement par ce changement.
  • Comme vous le verrez dans les prochains articles, il existe une amitié naissante entre ces fonctionnalités (RSS et VMQ). Ils vont vite devenir des amis… comme le beurre de cacahuète et la gelée…

Important: La désactivation de RSS n'est pas une configuration prise en charge sous Windows. Le support technique de Microsoft peut désactiver temporairement les flux RSS pour résoudre les problèmes éventuels liés à cette fonctionnalité. RSS ne doit pas être désactivé de manière permanente, ce qui laisserait Windows dans un état non pris en charge.

Les cartes réseau virtuelles sur Windows Server 2012 utiliseront, par défaut, un, un seul cœur pour traiter tout le trafic réseau entrant dans le système. Ce noyau est CPU0.

e.png

Cela signifiait qu'en l'absence de toute modification de votre part, avec une carte réseau et un pilote certifiés VMQ, le débit global de votre système resterait limité à ce que CPU0 pourrait atteindre. Pour remédier à cela, vous deviez indiquer à Windows que les files d'attente envoyaient leurs paquets à d'autres cœurs de processeur, comme indiqué dans les sections suivantes.

Activer / désactiver VMQ

Pour activer ou désactiver VMQ, utilisez les cmdlets Enable-NetAdapterVmq et Disable-NetAdapterVmq PowerShell sur les adaptateurs hôtes.

Remarque: En fonction de votre adaptateur spécifique, vous devrez peut-être également vérifier Get-NetAdapterAdvancedProperty et assurez-vous que l'adaptateur montre le lien.

f.png

Ensuite, identifiez le nombre de VMQ disponibles. Vous pouvez connaître le nombre de files d'attente disponibles sur votre carte réseau en exécutant l'applet de commande PowerShell Get ‑ NetAdapterVmq et en consultant la colonne. NumberOfReceiveQueues comme indiqué ici.

g.png

Si vos adaptateurs sont associés, le nombre total de files d'attente disponibles pour les périphériques connectés à l'équipe peut correspondre à la somme des files d'attente de tous les adaptateurs de l'équipe ou au nombre minimal de files d'attente disponibles sur l'un d'entre eux. adaptateur unique. Cela dépend des options de regroupement sélectionnées lors de la création de l’équipe. Pour plus d'informations, reportez-vous à la documentation NIC Teaming.

Pour les besoins de ce guide, nous utiliserons le conseillé mécanisme de somme des files d'attente qui oblige une équipe à utiliser le mode de regroupement indépendant du commutateur et le port Hyper-V ou l'équilibrage de charge dynamique.

Remarque: Dans Windows Server 2012 et 2012 R2, seul le regroupement LBFO était disponible. Nous déconseillons d'utiliser LBFO sur Windows Server 2016 et 2019 à moins que vous ne soyez sur un hôte natif (sans Hyper-V).

Engager des cœurs de processeur supplémentaires

Comme mentionné précédemment, Windows Server 2012 n'engageait par défaut que CPU0 sur NUMA0. Pour engager et basculer les affectations de cœurs de processeur utilisées par VMQ, utilisez la commande Set-NetAdapterVmq. Cette cmdlet utilise des paramètres similaires à Set-NetAdapterRSS. Il existe de nombreuses configurations possibles disponibles (pour plus d'informations, consultez la documentation de Set-NetAdapterVMQ). Toutefois, nous allons utiliser un exemple simple pour montrer comment utiliser les applets de commande.

Considérons un serveur doté de la configuration matérielle et logicielle suivante

  • 2 processeurs avec 10 cœurs et 10 processeurs logiques; L'hyperthreading est désactivéh.png

Remarque: Etant donné que les processeurs hyperthreaded sur le même processeur central partagent le même moteur d'exécution, l'effet est différent de celui de plusieurs processeurs principaux. Pour cette raison, RSS et VMQ n'utilisent pas de processeurs hyperthreaded.

  • 2 cartes réseau physiques
    • Des noms: pNIC01, pNIC02
    • 60 VMQ (NumberOfReceiveQueues) par interface

i.png

j.png

  • Les cartes réseau sont connectées à une équipe LBFO nommée de manière intuitive: LBFO
    • Mode Teaming: indépendant du commutateur
    • LoadBalancingAlgorithm: port Hyper-V

Remarque: Dans Windows Server 2016 et 2019, il n'est plus recommandé d'utiliser LBFO avec le commutateur virtuel

  • Un commutateur virtuel nommé LBFOvSwitch est associé à l'équipe LBFO

k.png

Avant de commencer à modifier quoi que ce soit, voyons s’il existe des différences dans la configuration NUMA des adaptateurs. Voyons d’abord si nous avons plusieurs nœuds NUMA.

l.png

Et comment les pNIC sont répartis sur ces nœuds NUMA

m.png

Comme vous pouvez le voir ci-dessus, les deux cartes réseau sont sur NumaNode 1. Si vos adaptateurs ont accès à différents nœuds NUMA, nous vous recommandons d'affecter la carte réseau aux processeurs de ce nœud NUMA afin d'améliorer les performances.

Voici la structure de base. Comme vous pouvez le constater, le commutateur virtuel ne peut actuellement «voir» qu’un seul processeur – CPU0

n.png

Si vous exécutez Get-NetAdapterVmq sur le système (maintenant associé), il ressemblera par défaut à ceci:

o.png

Plus précisément, le MaxProcessorNumber n'est pas défini.

q.png

Il y a quelques problèmes avec cette configuration:

  • CPU0 est engagé – CPU0 est généralement le processeur le plus surchargé du système. Ainsi, une machine virtuelle dont le VMQ atterrit sur ce processeur sera en concurrence avec tous les autres traitements de ce système. C’est mieux si nous pouvions éviter ce processeur.
  • Seul CPU0 est engagé – Actuellement, tous les ordinateurs virtuels utilisent ce processeur pour gérer le trafic réseau reçu. Comme nous avons beaucoup d'autres cœurs, nous devrions les utiliser pour que les machines virtuelles puissent obtenir de meilleures performances.
  • MaxProcessors est configuré à 8 et il y a 19 processeurs sur le système (à l'exception de CPU0); 10 par NUMA. Cela signifie que l'adaptateur n'affectera que les VMQ à 8 des processeurs disponibles.
  • Chevauchement de processeurs n’est pas idéal – Étant donné que nous sommes limités à une seule VMQ par carte réseau virtuelle et que les VMQ ne peuvent pas être réaffectées à un nouveau processeur si elles sont sous charge, nous devons minimiser les risques que différents adaptateurs attribuent des VMQ au même processeur.

Remarque: Si vous êtes en mode de file d'attente minimale (par exemple, en utilisant LACP ou un hachage d'adresse), les processeurs affectés aux NIC de l'équipe doivent être identiques. vous devez exécuter les mêmes commandes sur chaque carte réseau et ne pouvez pas séparer les cartes de la manière indiquée ci-dessous. Nous vous déconseillons de vous lancer en mode min-de-files d'attente. Si vous êtes mal configuré en fonction du mode de file d'attente défini, vous verrez l'événement 106. Consultez cet article de la Base de connaissances pour plus d'informations.

Pour remédier aux problèmes décrits précédemment, configurons la disposition de VMQ en processeur suivante de la manière suivante:

p.png

Si l’option Hyperthreading est activée, vous la visualisez comme ceci:

Annotation 2019-04-17 100721.jpg[EDIT] Image mise à jour pour inclure tous les processeurs applicables

En règle générale, nous vous recommandons d’affecter un nombre suffisant de processeurs afin de maximiser le débit disponible de la carte. Par exemple, si vous avez une carte réseau 10 GbE, le mieux serait de lui attribuer un minimum de 4 cœurs pour vous assurer que, dans le pire des cas, un adaptateur ne pouvant traiter que 3 Gbps environ sur chaque cœur, vous obtenez le maximum de vos cartes réseau.

Remarque: Certains clients choisissent d'ignorer le premier noyau des NUMA supplémentaires. Tout d'abord, son automatisation est simplifiée et, d'autre part, elle garantit des performances similaires à toutes les machines virtuelles, quel que soit l'adaptateur desservant leur trafic réseau reçu. Ceci est un choix client et n'est pas obligatoire comme le montre cet exemple.

Ensuite, exécutez ces commandes pour que pNIC01 attribue des VMQ aux processeurs 1 – 9

Set-NetAdapterVmq -Name pNIC01 -BaseProcessorNumber 1 -MaxProcessorNumber 9 -MaxProcessors 9

s.png

Set-NetAdapterVmq -Name pNIC02 -BaseProcessorNumber 10 -MaxProcessorNumber 19 -MaxProcessors 10 

t.png

BaseProcessorNumber: Nombre de cœurs de processeur le plus bas pouvant être utilisé par les files d'attente sur cette carte réseau

  • pNIC01 commence au noyau 1
  • pNIC02 commence au noyau 10

MaxProcessorNumber: Indique numériquement le nombre maximal de processeurs pouvant être utilisés par les files d'attente sur cette carte réseau

  • pNIC01 se termine au noyau 9
  • pNIC02 se termine au noyau 19

MaxProcessors: Le nombre maximal de cœurs de processeur de la plage ci-dessus pouvant recevoir une VMQ

  • pNIC01 peut affecter des VMQ à 9 processeurs
  • pNIC02 peut affecter des VMQ à 10 processeurs

Maintenant, la configuration ressemble à ceci:

u.png

Les VMQ sont une ressource finie dans le matériel. Comme vous l'avez probablement constaté dans certaines des captures d'écran précédentes, les cartes réseau de ces périodes ne disposaient pas de la même quantité de ressources qu'aujourd'hui et ne pouvaient donc pas générer autant de files d'attente.

Par défaut, toute machine virtuelle créée demanderait une VMQ. Toutefois, si l’hôte n’en a plus à distribuer, la machine virtuelle atterrira sur la file d’attente par défaut partagée par toutes les machines virtuelles ne disposant pas de file d’attente dédiée. Cela pose deux problèmes:

  • Si les machines virtuelles partagent une file d'attente, elles partagent la bande passante globale pouvant être générée par la puissance de traitement sur le cœur de processeur sélectionné.
  • À mesure que les ordinateurs virtuels migrent, ils vont atterrir sur un nouvel hôte qui risque de ne pas être en mesure de leur fournir le même niveau de performances que l'ancien.

Par conséquent, si vous avez un nombre élevé de machines virtuelles, assurez-vous d’abord d’optimiser l’emplacement de vos machines virtuelles. Si vous avez sur-provisionné le nombre de machines virtuelles par rapport au nombre de files d'attente disponibles, assurez-vous de n'allouer une file d'attente qu'aux machines virtuelles qui en ont besoin. décidez quels adaptateurs virtuels ont une bande passante élevée (par exemple, 3 à 6 Gbps) ou nécessitent une bande passante cohérente et désactivez VMQ sur les autres adaptateurs de machines virtuelles.

Pour marquer un adaptateur virtuel comme non éligible pour un VMQ, utilisez la commande Set-VMNetworkAdapter cmdlet et paramètre –VmqWeight 0. VmqWeight interprète la valeur 0 comme étant désactivée et toute valeur autre que zéro comme étant activée. Il n'y a pas de différence entre différentes valeurs non nulles.

Files d'attente allouées

Pour vérifier qu'une file d'attente a été allouée à une machine virtuelle, utilisez Get-NetAdapterVmqQueue et examinez le nom VMFriendlyName ou l'adresse MAC dans la sortie des tables.

a.png

Moniteur de performances

À l'aide de l'Analyseur de performances (démarrer> exécuter> perfmon), quelques compteurs sont utiles et peuvent aider à évaluer VMQ. Ajoutez les compteurs suivants sous le Processeur de commutation virtuelle Hyper-V Catégorie:

  • Nombre de VMQ – Nombre de processeurs VMQ affinités avec ce processeur
  • Paquets externes – Paquets indiqués à un processeur à partir de n'importe quelle carte réseau externe
  • Paquets internes – Paquets indiqués à un processeur depuis une carte réseau interne, telle qu'une vmNIC ou une vNIC

Paquets traités sur le mauvais processeur

Au cours de la période 2012, nous avons souvent vu des paquets traités sur les mauvais processeurs VMQ et ne respectant pas la matrice de processeurs définie. Ce problème est en grande partie résolu par les mises à jour du pilote et du microprogramme de la carte réseau.

Les symptômes incluent une chute brutale inexpliquée du taux de traitement ou tout simplement un faible débit. Cela peut être facilement résolu en utilisant les compteurs ci-dessus.

Pour résumer ce que nous avons couvert ici, il existe plusieurs exigences

  • Installer les derniers pilotes et micrologiciels
  • Groupe de processeurs activé par défaut – CPU0
  • Configurez le système pour éviter CPU0 sur les systèmes non hyperthreadés et CPU0 et [Edit] CPU2 CPU1 sur les systèmes hyperthreaded (par exemple BaseProcessorNumber devrait être 1 ou 2)
  • Configurez le MaxProcessorNumber pour établir qu'un adaptateur ne peut pas utiliser un processeur supérieur à celui-ci
  • Configurer MaxProcessors Pour déterminer le nombre de processeurs disponibles sur la liste, une carte réseau peut étendre simultanément les VMQ et optimiser le débit des adaptateurs. Nous vous recommandons de le configurer en fonction du nombre de processeurs dans la matrice de processeurs.
  • Testez la charge de travail – ne négligez aucun effort

Autres bonnes pratiques

Ces meilleures pratiques devraient être associées aux informations contenues dans le Résumé des exigences section ci-dessus.

  • Utiliser la somme des files d'attente pour maximiser le nombre de VMQ disponibles
  • Ne couvrez pas une seule file d’adaptateurs sur des nœuds NUMA
  • Si vous utilisez le regroupement, spécifiez l'option Port indépendant, Hyper-V ou Indépendant du commutateur pour vous assurer que vous disposez du nombre maximal de VMQ disponibles. nous recommandons le port Hyper-V
  • Si vous avez plus de VM que de VMQ, assurez-vous de définir quelles machines obtiendront les VMQ afin d'obtenir un semblant de performance cohérente.
  • Faire NE PAS désactiver RSS sauf si le support de Microsoft vous le demande

Résumé des avantages

  • Utilisation complète de la carte réseau – Avec des ressources de traitement adéquates, la vitesse maximale de l'adaptateur physique connecté à un commutateur virtuel peut être utilisée si elle est configurée correctement.

Résumé des inconvénients

  • File d'attente par défaut – Il n'y a qu'une seule file d'attente par défaut – Tous les ordinateurs virtuels qui ne disposent pas de leur propre file d'attente partageront cette file d'attente et obtiendront des performances inférieures à celles des autres ordinateurs virtuels
  • Affectation statique – Étant donné que les files d'attente sont attribuées de manière statique et ne peuvent plus être déplacées une fois établies, si vous partagez un cœur de processeur avec d'autres machines virtuelles «bruyantes», les performances peuvent être incohérentes.
  • Une VMQ par carte réseau virtuelle – Une seule file d'attente est affectée à chaque vNIC ou vmNIC – Un seul adaptateur virtuel peut atteindre un maximum de 6 Gbps sur un système bien configuré.

Comme vous pouvez le constater, un certain nombre d'options de configuration complexes doivent être prises en compte lors du déploiement de VMQ afin d'atteindre le débit maximal de votre système. Dans les prochains articles, vous verrez comment nous améliorons la fiabilité et les performances, en augmentant en définitive la densité des ordinateurs virtuels de votre système dans Windows Server 2012 R2, 2016 et 2019.

Merci d'avoir lu,

Dan Cuomo

Click to rate this post!
[Total: 0 Average: 0]

Commentaires

Laisser un commentaire

Votre commentaire sera révisé par les administrateurs si besoin.