Serveur d'impression

Accélérations synthétiques en bref – Windows Server 2016 – Communauté Microsoft Tech – Serveur d’impression

Par Titanfall , le 11 juin 2019 - 17 minutes de lecture

Salut les gens,

Dan Cuomo retour pour notre prochain épisode de cette série de blogs sur les accélérations synthétiques. Windows Server 2016 marquait un point d'inflexion dans le monde de l'accélération synthétique sous Windows. Dans cet article, nous allons donc parler des modifications architecturales, des nouvelles fonctionnalités et des modifications de configuration requises par rapport aux deux derniers systèmes d'exploitation.

Avant de commencer, voici les pointeurs des blogs précédents:

N'oubliez pas qu'en raison des modifications apportées à Windows Server 2016, de nombreux détails de Windows Server 2012 / R2 deviennent inutiles, tandis que d'autres deviennent encore plus importants. Par exemple, vRSS devient plus important alors que les avantages de Dynamic VMQ, initialement mis en œuvre dans Windows Server 2012 R2, sont surpassés dans cette version. Nous terminerons cette série dans un futur article couvrant Windows Server 2019 (et le nouveau et amélioré Dynamic VMMQ)!

Mais avant d’arriver à la grande finale de Windows Server 2019, parlons des fondements de Windows Server 2016 et des avancées majeures qu’ils ont apportées aux performances du réseau synthétique (via le commutateur virtuel). En résumé, il s’agit du chemin de données synthétique; tout le trafic entrant doit traverser le commutateur virtuel (vSwitch) de la partition parent avant d'être reçu par l'invité:

1.png

Architecture de la carte réseau dans Windows Server 2016

Windows Server 2016 a introduit une nouvelle architecture dans la carte réseau qui affecte la mise en œuvre de VMQ. Si vous vous souvenez de l'article sur Windows Server 2012, vous vous souviendrez peut-être que la carte réseau crée un filtre basé sur les combinaisons MAC et VLAN de chaque vmNIC sur le commutateur v-switch Hyper-V. Ainsi, chaque combinaison de MAC et de VLAN enregistrée sur le commutateur v-switch Hyper-V serait transmise à la carte réseau pour demander le mappage d’une VMQ.

Remarque: Bien pas exactement chaque combinaison. Les VMQ doivent être demandées à l'aide des propriétés de la machine virtuelle afin que seules les machines virtuelles dotées des propriétés appropriées soient transmises à la carte réseau pour l'affectation d'une file d'attente. Le reste, comme vous vous en souvenez peut-être, atterrit dans la file d'attente par défaut.

Toutefois, certains adaptateurs supplémentaires sous forme de commutateur Ethernet intégré (commutateur NIC) ont été intégrés aux adaptateurs réseau physiques. Lorsque Windows détecte qu'une carte réseau possède un commutateur de carte réseau, il lui demande de mapper un port de commutateur de carte réseau (vPort) sur une file d'attente (au lieu d'attribuer une file d'attente au filtre MAC + VLAN mentionné précédemment). Voici un aperçu de l’architecture VMQ héritée (filtrée MAC + VLAN):

2.png

Voici la nouvelle architecture. Si vous regardez la carte réseau au bas de l'image, vous pouvez voir qu'une file d'attente est maintenant mappée sur un vPort et que vPort est mappé sur un processeur.

3.png

Dans les systèmes d'exploitation antérieurs, le commutateur NIC était utilisé uniquement lorsque SR-IOV était activé sur le commutateur virtuel. Cependant, dans Windows Server 2016, nous avons séparé l'utilisation du commutateur de carte réseau de SR-IOV et nous l'utilisons maintenant pour bénéficier de nombreux avantages.

VRSS sans le déchargement

Si vous utilisez Windows Server 2016, vous êtes probablement NE PAS dans cette situation exacte. Cependant, cette section est importante pour comprendre le grand saut de performances que vous verrez dans la section suivante (donc ne sautez pas cette section).

La mise à l'échelle de la réception virtuelle (vRSS) a été introduite pour la première fois dans Windows Server 2012 R2. En tant que révision, vRSS a deux responsabilités principales sur l'hôte:

  • Création du mappage des VMQ sur les processeurs (appelé table d'indirection)
  • Distribution de paquets sur les processeurs

Avec la distribution de paquets VMQ héritée dans Windows Server 2012 R2, vRSS étend la diffusion RSS sur des processeurs supplémentaires, dépassant ainsi le débit qu'un seul ordinateur virtuel et processeur peut fournir.

4.png

Bien que cela ait permis d’améliorer considérablement le débit par rapport à Windows Server 2012, la distribution de paquets (étalement RSS) a été effectuée sous forme de logiciel et le traitement a été encombré (ceci est couvert dans l’article R2 de 2012, donc je ne passerai pas beaucoup de temps là-dessus). Cela limitait le débit potentiel d'une carte réseau virtuelle à environ 15 Gbps dans Windows Server 2012 R2.

RemarqueRemarque: si vous comparez simplement vRSS et VMQ sur Windows Server 2012 R2 à Windows Server 2016, vous remarquerez que votre débit de traitement avec les mêmes accélérations que celles activées est naturellement amélioré. C’est pour plusieurs raisons, mais c’est essentiellement l’amélioration des pilotes et de l’efficacité des systèmes d’exploitation. C'est l'un des avantages de la mise à niveau vers le dernier système d'exploitation et de l'installation des derniers pilotes / micrologiciels.

VMMQ

(J’ai dit de ne pas sauter la dernière section! Si vous l’avez fait, retournez-le et lisez-le d’abord!)

familyguy.gif

Le gros avantage du commutateur de carte réseau est la possibilité de décharger la fonction de distribution de paquets effectuée par vRSS vers la carte réseau. Cette fonctionnalité est connue sous le nom de file d'attente multiple de machine virtuelle (VMMQ) et nous permet d'affecter plusieurs VMQ au même vPort dans le commutateur de carte réseau, comme vous pouvez le voir sur l'image ci-dessous.

5.png

Désormais, au lieu d’une solution logicielle désordonnée qui induit une surcharge du processeur et traite les paquets à plusieurs endroits, la carte réseau place simplement le paquet directement sur le processeur prévu. Le hachage RSS est utilisé pour répartir le trafic entrant entre les files d'attente attribuées au vPort.

Dans le dernier article, nous avons expliqué comment VMQ et RSS avaient noué une amitié naissante (voir la référence «Orange Mocha Frappuccinos»). Vous devriez maintenant voir à quel point le RSS est essentiel à la vitalité de VMQ; Ils sont comme une grenouille et un ours qui chantent l’Amérique. Ils avancent bien. ce sont vraiment des oiseaux d'une plume; ils sont dans le même bateau.

MuppetMovie.gif

Désormais, les paquets ne doivent être traités qu'une seule fois avant de se diriger vers leur destination, la carte réseau virtuelle. Le résultat est un hôte beaucoup plus performant et un débit accru vers la carte réseau virtuelle. Avec suffisamment de puissance de traitement disponible, vous pouvez dépasser 50 Gbps.

Gestion des propriétés vRSS et VMMQ d’une carte réseau virtuelle

Dans Windows Server 2016, VMMQ était désactivé par défaut. Après tout, c’était une toute nouvelle fonctionnalité et après la débâcle «Great Windows Server 2012 VMQ», nous avons jugé préférable de désactiver les nouveaux déchargements par défaut jusqu’à ce que la carte réseau et le système d’exploitation aient la possibilité de prouver qu’ils peuvent jouer ensemble.

Vérifier que vRSS est activé pour un vNIC

Cela devrait déjà être activé (rappelez-vous que c'est le composant du système d'exploitation qui dirige le déchargement matériel, VMMQ), mais vous pouvez voir les paramètres en exécutant cette commande pour un vmNIC:

1.png

Et maintenant, un hôte vNIC – Oh oui! Nous avons également activé vRSS pour les vNIC hôtes dans cette version! Ce n'était pas disponible sur 2012 R2 auparavant.

2.png

Remarque: Si cela a été désactivé par inadvertance et que vous souhaitez le réactiver, veuillez consulter Set-VMNetworkAdapter.

Activer VMMQ

Commencez par vérifier si VMMQ est activé. Comme mentionné précédemment, il n'est pas activé par défaut sur Server 2016.

3.png

Maintenant, vérifions que les fonctionnalités matérielles requises sont activées. Pour ce faire, utilisez Get-NetAdapterAdvancedProperty pour interroger le périphérique (ou utilisez les propriétés du gestionnaire de périphériques pour l'adaptateur) pour les trois propriétés suivantes:

Commutateur virtuel RSS4.png

Files d'attente de machines virtuelles5.png

Recevez une mise à l'échelle latérale6.png

Si l'un des paramètres ci-dessus est désactivé (0), veillez à les activer avec Set-NetAdapterAdvancedProperty.

Maintenant, activons VMMQ sur la vNIC en exécutant Set-VMNetworkAdapter:7.png

Enfin, vérifiez que VMMQ est activé:

8.png

Une dernière chose… Dans l’illustration ci-dessus, vous pouvez voir le nombre de paires de files d’attente VMMQ (voir l’article de 2012 sur l’architecture de la carte réseau – une file d’attente est techniquement une paire de files d’attente) attribué à cette carte réseau virtuelle. Cela montre que la demande concernait 16 personnes. Pourquoi 8 seulement ont-elles été affectées?

Commencez par comprendre la perspective de chaque sortie de propriété. VMMQQueuePairRequested est ce que vRSS a demandé en votre nom – dans ce cas 16. VMMQQueuePairs est le nombre réel attribué par le matériel.

Comme vous le savez dans notre précédente applet de commande Get-NetAdapterAdvancedProperty ci-dessus, chaque carte réseau a défini des valeurs par défaut qui régissent ses propriétés. le * MaxRssProcessors propriété (intuitivement) définit le nombre maximal de processeurs RSS pouvant être attribués à n'importe quel adaptateur, cartes réseau virtuelles inclus.

9.png

Enfin le * NumRSSQueues définit combien de files d'attente peuvent être attribuées.

10.png

Nous pouvons y remédier en modifiant ces propriétés à l'aide de Set-NetAdapterAdvancedProperty ou du gestionnaire de périphériques.

1.png

2.png

3.png

4.png

Maintenant, vérifiez que la carte réseau virtuelle a maintenant 16 paires de files d'attente:

5.png

Remarque: Vous êtes-vous déjà demandé pourquoi un astérisque (*) se trouvait devant les propriétés Get-NetAdapterAdvancedProperty?

Ces mots clés sont connus sous le nom de mots-clés de registre avancés bien connus, qui constituent un contrat logiciel normalisé entre le système d'exploitation et la carte réseau. Tout mot clé répertorié ici sans astérisque avant est défini par le fournisseur et peut être différent (ou ne pas exister) en fonction de l'adaptateur et du pilote que vous utilisez.

En diminuant le nombre de VMMQQueuePairsRequested vous disposez d'un mécanisme simple pour gérer le débit disponible dans une machine virtuelle. Vous devez attribuer une paire de files d’attente par groupe de 4 Gbit / s que vous souhaiteriez obtenir avec une VM.

6.png

Si vous choisissez de le faire, gardez à l’esprit deux choses. Tout d’abord, VMMQ n’est pas un véritable mécanisme de qualité de service. Votre kilométrage peut varier car le débit réel dépend du système et des ressources disponibles.

Deuxièmement, VMMQ évolue considérablement mieux que VMQ seul en grande partie en raison des améliorations apportées à la file d'attente par défaut décrites dans la section suivante, de sorte que vous n'aurez peut-être pas besoin de gérer l'allocation des files d'attente de manière aussi stricte que par le passé.

Gestion des files d'attente par défaut

Dans la dernière section, nous avons activé VMMQ pour une carte réseau virtuelle spécifique. Toutefois, vous souhaiterez peut-être activer VMMQ pour la file d'attente par défaut. Il est généralement recommandé d'activer VMMQ pour la file d'attente par défaut.

Pour rappel, la file d'attente par défaut est la file pouvant s'appliquer à plusieurs périphériques. Plus précisément, si vous n’obtenez pas de VMMQ, vous les utiliserez. Auparavant, tous les ordinateurs virtuels qui ne pouvaient pas recevoir leur propre VMQ partageaient la file d'attente par défaut. Maintenant, ils partagent plusieurs files d'attente (par exemple, VMMQ).

7.png

Vous pouvez voir ci-dessus que la même configuration est requise pour la DefaultQueueVMMQPairs. La seule différence est qu'au lieu de définir la configuration sur la carte réseau virtuelle à l'aide de Set-VMNetworkAdapter, vous définissez la configuration sur le commutateur virtuel comme suit:

8.png

9.png

Désormais, toute machine virtuelle incapable de recevoir ses propres files d'attente bénéficiera de 16 (ou de tout ce que vous configurez) pour partager le workload.

Matrices de processeur

Dans Windows Server 2016, il n'est plus nécessaire de définir les matrices de processeurs avec Set-NetAdapterVMQ ou Set-NetAdapterRSS. On m'a demandé si vous pouvez toujours configurer ces paramètres si vous le souhaitez, et la réponse est oui. Cependant, lorsque cela est utile, les scénarios sont rares. Pour une utilisation générale, ce n'est plus une obligation.

Comme vous pouvez le voir sur l'image ci-dessous, RSSProcessorArray inclut les processeurs par défaut et ils sont commandés par NUMA Distance.

10.png

#DownWithLBFO

Vous avez peut-être vu notre campagne Twitter mineure sur l’élimination de LBFO de votre environnement…

11.png

Cette recommandation a plusieurs raisons, mais elle se résume à ceci:

LBFO est notre technologie de regroupement plus ancienne qui ne fera l'objet d'aucun investissement futur. Elle n'est pas compatible avec de nombreuses fonctionnalités avancées et ses performances et sa stabilité ont été dépassées par nos nouvelles technologies (SET).

Remarque: Si vous débutez avec Switch Embedded Teaming (SET), vous pouvez consulter ce guide pour un aperçu.

Nous aurons un blog qui va déballer cette déclaration un peu plus, mais parlons-en en termes d’accélérations synthétiques. LBFO ne prend pas en charge les déchargements tels que VMMQ. VMMQ est un capacité avancée qui réduit la consommation du processeur hôte et permet débit de réseau bien meilleur aux machines virtuelles. En d'autres termes, vos utilisateurs (ou clients) seront plus satisfaits de VMMQ en ce sens qu'ils peuvent généralement obtenir le débit souhaité, quand ils le souhaitent, à condition que vous disposiez de la puissance de traitement et du matériel réseau nécessaires pour répondre à leurs demandes. Si vous souhaitez utiliser VMMQ et que vous recherchez une technologie de regroupement, vous devez utiliser Switch Embedded Teaming (SET).

Pour ce faire, ajoutez simplement -EnableEmbeddedTeaming $ true à votre cmdlet New-VMSwitch.

12.png

Résumé des exigences

Nous continuons à réduire les exigences de l'administrateur système par rapport aux versions précédentes.

  • Installer les derniers pilotes et micrologiciels
  • Groupe de processeurs activé par défaut – CPU0. Cela a été modifié à l'origine en 2012 R2 pour activer VRSS (sur l'hôte). Toutefois, cela inclut désormais les cartes réseau virtuelles de l'hôte et les files d'attente matérielles (VMQ / VMMQ).
  • Configurez le système pour éviter CPU0 sur les systèmes non hyperthreadés et CPU0 et CPU1 sur les systèmes hyperthreadés (par exemple, BaseProcessorNumbers doit être 1 ou 2 en fonction de l'hyperthreading).
  • Configurez MaxProcessorNumber pour établir qu'un adaptateur ne peut pas utiliser un processeur supérieur à celui-ci. Le système va maintenant gérer cela automatiquement dans Windows Server 2016 et nous vous recommandons donc de ne pas modifier les valeurs par défaut.
  • Configurez MaxProcessors pour établir combien de processeurs de la liste disponible une carte réseau peut répartir simultanément les VMQ. Ceci est inutile en raison des améliorations apportées à la file d'attente par défaut. Vous pouvez toujours choisir de le faire si vous limitez les files d'attente en tant que mécanisme rudimentaire de qualité de service, comme indiqué précédemment, mais cela n'est pas obligatoire.
  • Activer VMMQ sur les cartes réseau virtuelles et le commutateur virtuel. Ceci est nouveau car cette fonctionnalité n'existait pas avant cette version et, comme indiqué, nous avons désactivé les nouveaux déchargements.

Résumé des avantages

  • Répartir sur plusieurs processeurs virtuels (vRSS dans l'invité) – Les processeurs virtuels ont été supprimés en tant que goulot d'étranglement (mis en œuvre à l'origine en 2012 R2).
  • Déchargement du positionnement des paquets vRSS – Des processeurs supplémentaires peuvent être engagés par vRSS (création de la table d'indirection mise en œuvre en 2012 R2). Il est désormais possible de placer des paquets sur le processeur approprié dans la carte réseau, améliorant ainsi les performances d'une carte réseau virtuelle individuelle jusqu'à +50 Gbps avec les ressources disponibles adéquates. Cela représente une autre amélioration 3x par rapport à Windows Server 2012 R2 (et 6x par rapport à Windows Server 2012)!

Remarque: Certains ont fait remarquer qu'ils n'avaient pas besoin qu'une machine virtuelle individuelle reçoive +50 Gbps par elle-même. Bien que ces scénarios soient (actuellement) moins courants, ils passent à côté de l’essentiel. L’avantage réel est que le système peut traiter +50 Gbps, qu’il s’agisse de 100 VM / 50 Gbps == 2 Gbps par VM ou de +50 Gbps pour 1 VM. Vous choisissez comment diviser la bande passante disponible.

  • Plusieurs files d'attente pour la file d'attente par défaut – Auparavant, la file d'attente par défaut était un goulot d'étranglement pour toutes les machines virtuelles qui ne pouvaient pas recevoir leur propre file d'attente dédiée. Désormais, ces machines virtuelles peuvent exploiter VMMQ dans la file d'attente par défaut, ce qui permet une plus grande mise à l'échelle du système.
  • Gestion de la file d'attente par défaut – Vous pouvez choisir le nombre de files d'attente pour la file d'attente par défaut et chaque carte réseau virtuelle.
  • Files d'attente pré-allouées – En pré-allouant les files d’attente aux machines virtuelles, nous pouvons répondre à la demande de charges de travail réseau en rafale.

Résumé des inconvénients

  • VMMQ est désactivé par défaut – Vous devez activer VMMQ individuellement ou utiliser un outil pour l'activer.
  • Aucune affectation dynamique de files d'attente – VMQ dynamique est obsolète avec l'utilisation de VMMQ, ce qui signifie qu'une fois qu'une file d'attente a été mappée sur un processeur, elle ne sera pas déplacée en réponse à l'évolution des conditions du système.
  • Files d'attente pré-allouées – Cela constitue également un inconvénient, car nous risquons de gaspiller des ressources système sans pouvoir les réaffecter.

L’architecture redéfinie de la carte réseau (commutateur de carte réseau) a permis à VMMQ de représenter une autre avancée importante en termes de performances et d’efficacité du système synthétique. Si vous utilisez le chemin de données synthétique, vous bénéficierez d’un énorme coup de pouce par rapport à ce que vRSS et Dynamic VMQ peuvent à eux seuls apporter, permettant ainsi une nouvelle amélioration de la performance par 3. En outre, VMMQ améliore la densité du système (regroupant plus de machines virtuelles sur le même hôte) et offre une expérience utilisateur plus cohérente, car elles pourront exploiter VMMQ dans la file d'attente par défaut. Enfin, Switch Embedded Teaming (SET) est officiellement devenu notre option de regroupement recommandée dans cette version, en partie grâce à sa prise en charge des déchargements avancés tels que VMMQ.

J'espère que vous avez apprécié les trois premiers articles de cette série. La semaine prochaine, nous terminerons avec le dernier versement décrivant Dynamic VMMQ et notre première accélération non nommée VMQ ou RSS!

Dan "Accélération" Cuomo

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

Commentaires

Laisser un commentaire

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