Vous êtes sur la page 1sur 10

Hyper-V 2012 R2, optimisation réseau Deep Dive.

Dans notre dernier article Optimisation réseau, nous avons décrit comment
RSS (Receive Side Scaling) et de son pendant pour les machines
virtuelles VMQ (Virtual Machine Queue) pouvait améliorer drastiquement
les performances réseau de votre infrastructure Hyper-V.

Avec ce nouvel article, nous allons rentrer beaucoup plus loin dans le
détail de ces fonctions afin d’assurer performances et scalabilité à votre
plateforme Hyper-V.

Petit Rappel : Ne pas confondre RSS et vRSS. RSS est une fonction physique des cartes physiques, vRSS est une
émulation de RSS sur une carte virtuelle. vRSS repose sur VMQ. Relisez notre article Hyper-V 2012 Optimisation
Réseau pour plus de détails.

Comprendre VMQ.

Comme nous l’avons déjà décrit dans l’article « Optimisation Réseau Hyper-V 2012 R2», VMQ et RSS sont des
fonctionnalités matérielles des cartes réseau utilisées par Hyper-V.

Petit détail important, si vous disposez de cartes 10Gbit VMQ est activé par défaut. Ce n’est cependant pas le cas
si vous disposez de carte 1Gbit !

Pour Changer cette configuration, vous devez ajouter la clef de registre suivante :

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\VMSMP\Parameters\Below
TenGigVmqEnabled
DWORD = 1

Pour vérifier si votre carte supporte les VMQ, vous pouvez vous rendre dans les propriétés avancées
de votre carte réseau. Vous pouvez aussi utiliser la commande Powershell suivante :
Get-NetAdaptervmq|ft name, enabled, NumberOfReceiveQueues

Ici on peut voir 4 cartes physiques avec 30 files chacune (Le nombre de files par carte dépend de votre modèle).
On peut aussi voir que VMQ n’est pas actif sur toutes les cartes. C’est parce que seule les cartes associées
à un vSwitch utilisent VMQ. Connecter un vSwitch à une carte réseau physique active automatiquement VMQ
(Sur les cartes 10Gbit cf. remarque plus haut).

Le nombre total de files dépend ensuite du type de teaming que vous allez configurer.

Deux modes sont possibles.

 Min Queues : Le nombre de files disponibles correspond au plus petit nombre exposé par une des cartes
du Team.

 Sum of Queues : Le nombre de files disponibles correspond à la somme des Queues des cartes du
Team.

Le tableau suivant résume les différents modes en fonction de l’algorithme de Load Balancing.
Address Hash Hyper-V Port Dynamic
Switch Dependent Min Queues Min Queues Min Queues
(LACP inclus)
Switch Min Queues Sum of Queues Sum of Queues
Independent

Note : Le mode Dynamic est le mode recommandé pour Hyper-V 2012 R2.

Exemple :

 Un team LACP/Dynamic de 2 cartes 10Gbit de 30 files chacune offre 30 files VMQ au total.

 Un team Switch Independant/Dynamic de 2 cartes 10Gbit de 30 files chacune offre 60 files VMQ au
total !

Le nombre de files disponible n’est pas la seule conséquence du mode de teaming, en effet suivant que l’on soit
en « Min Queues » ou « Sum of Queues » il est nécessaire de configurer différemment la façon dont les files sont
associées avec les Processeurs Logiques. Nous verrons ce point un peu plus bas, mais pour le moment attardons-
nous un peu sur la manière dont VMQ effectue la répartition de la charge réseau.

VMQ Dynamic

Avant 2012 R2, les VMQ étaient associées de manière statique avec un processeur logique. Depuis 2012 R2,
l’association des VMQ est dynamique, les VMQ peuvent être associées à différents processeurs en fonction de la
charge (Ce fonctionnement reprend exactement celui de RSS).

Chaque carte disposant de VMQ activé dispose des propriétés suviantes (On retrouve ces mêmes propriétés pour
RSS).

 BaseProcessorNumber (Valeur par défaut 0): Indice du premier processeur logique utilisable.


 MaxProcessorNumber (valeur par défaut 0=Max) Indice du dernier processeur logique
utilisable
 MaxProcessors (valeur par défaut 0=Max): Nombre maximum de processeur logique
utilisables
Nous avons donc « BaseProcessorNumber » et « MaxProcessorNumber » qui définissent notre plage de
processeurs logiques utilisable et MaxProcessors qui définit le nombre de processeurs logiques qui seront
réellement utilisés.
 

Exemple :

get-netadaptervmq [NOM_CARTE] |fl -Property *

On peut voir ici que les 30 files sont réparties sur tous les processeurs (pas de base processor ni de
max processor de renseigné).
 

Toutes les VMQ démarrent donc sur le même processeur logique (BaseProcessorNumber). Le nombre de
processeurs alloués augmente ou diminue en fonction de la charge.

Par défaut, le processeur de base est LP0. On peut voir ici grâce au compteur « Hyper-V Virtual Switch
Processor » que toute les VMQ sont associées au processeur Logique LP0 car il dispose d’une faible charge. Si la
charge du LP0 dépasse 80%, alors les files sont réparties sur d’autres LP (uniquement les LP pairs, car VMQ
n’utilise que des cœurs physiques), dans la limite des files disponibles.

Pour RSS, le fonctionnement est similaire, le nombre de files dépend du modèle de votre carte.

Ci-dessous, notre carte dispose de 8 files, ce qui signifie qu’elle ne pourra pas utiliser plus de 8 processeurs
logiques à la fois, et ce même si la valeur de la propriété MaxProcessor est configurées à une valeur supérieure.

 
 

Si la propriété MaxProcessor est configurée à une valeur inférieure au nombre de queue disponibles, le système
réduira automatiquement la valeur de « NumberOfReceiveQueues ».

Cette carte peut donc utiliser 8 files qui seront réparties dynamiquement sur 16 processeurs logiques entres le LP
0 (BaseProcessor) et le LP 38 (MaxProcessor).

Note : Si généralement RSS n’utilise que les cœurs physiques, certains modèles de cartes peuvent tirer partis de
l’hyperthreading et donc utiliser tous les processeurs logiques.

Dans le vif du sujet, Tunning de VMQ et de RSS

Comme nous n’avons déjà expliqué, VMQ est le pendant de RSS dans le monde virtuel. Le fonctionnement de
RSS est très similaire à VMQ dans sa manière d’utiliser les ressources CPU.

Dans notre précèdent article, nous avons vu que dans certaines configuration Hyper-V sous Windows Serveur
2012 R2, il est nécessaire d’utiliser RSS et VMQ de concert pour obtenir les meilleurs performances (vRSS n’étant
pas disponible dans la partition parent sous Windows 2012R2, ce qui est corrigé dans Windows 2016).

Dans cette architecture, le team de la partition parent va utiliser RSS, alors que les VM connectées au vSwitch
utilisent VMQ.
Cela signifie que RSS et VMQ risquent de rentrer en concurrence pour les ressources CPU.
 

Dans ce tableau, nous avons représenté le mapping par défaut entre les processeurs logiques et les différentes
files (RSS et VMQ) d'un serveur Bi-Socket (2x10 Coeurs + HT) . Pour plus de lisibilité, nous n’avons pas
représenté les processeurs logiques impairs, car ceux-ci ne sont pas utilisés par VMQ et RSS*.

*Certains modèles de cartes tirent partis de l’hyperthreading pour RSS.

 
Note : Gardez à l’esprit que le nombre de files VMQ et RSS dépend du modèle de votre carte et du mode de
teaming. Dans notre exemple, nos cartes disposent de 8 à 16 files RSS et de 30 à 60 files VMQ (suivant le mode
de teaming « Min Queues » ou « Sum Of Queues »).

 Le team de management (Carte 1 Port 1 & Carte 2 Port 1) utilise RSS car n’utilise pas de vSwitch.

 Le team pour les VM clientes (Carte 1 Port 1 & Carte 2 Port 1) utilise VMQ

Déplacer le BaseProcessor VMQ et RSS

Comme nous l’avons vu, VMQ, mais aussi RSS assignent dynamiquement les différents flux réseaux de nos VM à
des processeurs logiques. Par défaut, le « home processor » est le LP0. Hors le LP0 est aussi le processeur sur
lequel tournent de nombreux processus de la partition parent.

Plus important encore, le LP0 est aussi le processeur utilisé par la « Default Queue » qui récupère la charge
réseau de tous les flux non éligibles à une file dédiée.

 Les paquets Broadcast et Multicast

 Les VM sans services d’intégration

 Les VM n’ayant pu se voir attribuer une files VMQ

Si le serveur Hyper-V héberge plus de carte virtuelle que de files disponible, c’est la « default queue » qui
récupère le travail, et donc le LP0.

Ex : Je dispose de 30 files sur mon serveur. Le serveur contient 32 VM équipée d’une seule carte réseau virtuelle.
Cela signifie que 2 cartes virtuelles seront gérées par le LP0.

On comprend dès lors l’importance que l’on doit accorder à VMQ !

Un des premier best practice est donc de déplacer le « BaseProcessorNumber » pour éviter le LP0.

Exemple :
#Pour VMQ
set-NetAdaptervmq -name [NOM_Interface1] -BaseProcessorNumber 2
set-NetAdaptervmq -name [NOM_Interface2] -BaseProcessorNumber 2
#Pour RSS
set-NetAdapterRss -name [NOM_ Interface3] -BaseProcessorNumber 2
set-NetAdapterRss -name [NOM_ Interface4] -BaseProcessorNumber 2

Dans cet exemple, nous utilisons le LP2 comme "BaseProcessorNumber" pour l’ensemble de nos cartes.

Note : Comme VMQ et RSS n’utilisent que les cœurs physiques (indices pairs), même si vous configurez votre
BaseProcessorNumber à 1, vous constaterez que vos files sont déplacées sur le LP2.

Nous avons désormais libéré le base processor, mais nous pouvons encore faire mieux. En effet, RSS et VMQ
restent associés aux mêmes processeurs logiques.

Optimiser la répartition des Files

Selon votre Teaming, il existe différentes recommandations pour obtenir des performances optimales (Cf. Tableau
plus haut).

 Min Queues : Les membres du team peuvent utiliser les mêmes Logical Processor.

 Sum of Queues : Assurez-vous que chaque carte du team soit associée à un jeu de processeur dédié.

Exemple ci-dessous en mode « Min Queues », nous avons modifié l’allocation des LP pour éviter le recouvrement
entre RSS et VMQ.

Min Queue Mode

#Pour RSS
set-NetAdapterRSS -name [NOM_Interface1] -BaseProcessorNumber 2 –
MaxProcessorNumber 18
set-NetAdapterRSS -name [NOM_Interface2] -BaseProcessorNumber 2 –
MaxProcessorNumber 18
#Pour VMQ
set-NetAdapterVMQ -name [NOM_ Interface3] -BaseProcessorNumber 20 –
MaxProcessorNumber 38
set-NetAdapterVMQ -name [NOM_ Interface4] -BaseProcessorNumber 20 –
MaxProcessorNumber 38

 
Bien sûr, vous pouvez revoir la répartition du nombre de processeurs alloué à VMQ ou à RSS. Il pourrait en effet
être pertinent d’allouer plus de LP à VMQ qu’a RSS.

Sum of Queue Mode

Dans ce mode il est recommandé de dédier les processeurs logiques par interfaces.

#Pour RSS
set-NetAdapterRSS -name [NOM_Interface1] -BaseProcessorNumber 4 –
MaxProcessorNumber 10
set-NetAdapterRSS -name [NOM_Interface2] -BaseProcessorNumber 12 –
MaxProcessorNumber 18
#Pour VMQ
set-NetAdapterVMQ -name [NOM_ Interface3] -BaseProcessorNumber 20 –
MaxProcessorNumber 28
set-NetAdapterVMQ -name [NOM_ Interface4] -BaseProcessorNumber 30 –
MaxProcessorNumber 38

Note : Pour des raisons de symétrie, nous avons déplacé le « base processor » de RSS sur le LP4.

Topologie NUMA et RSS, un point à ne pas négliger !

En plus de la modification du mappage des processeurs logiques avec les différentes files, il faut absolument
prendre en compte l'association des cartes avec les noeuds NUMA.

En effet, le load balancing de files RSS entre différents nœuds NUMA peut conduire à une dégradation des
performances.

Avec RSS, les propriétés « Profile » et « Numanode » vous permettent d’optimiser l’utilisation de la carte en
fonction de la topologie NUMA.

Ci-dessous, les différents réglages possible de la propriété "Profile".


Profile Name Description
Closest Allocation dynamique des Queues. Les processeurs logiques dont l’index est le plus proche
du Base Processor est préféré (C'est le réglage par défaut).
ClosestStatic Allocation statique des Queues. Les processeurs logiques dont l’index est le plus proche du
Base Processor est préféré.
NUMA Allocation dynamique des Queues en « round robin » sur les différents nœuds Numa.
NUMAStatic Allocation Statique des Queues en « round robin » sur les différents nœuds Numa.
Conservative Allocation Statique des Queues sur le plus petit nombre de processeurs logique possible.
Cette option permet de réduire les interruptions.

La propriété Numanode permet de définire le nœud NUMA sur lequel l’interface réseau viendra consommer de la
mémoire. Assurez vous que les cartes membres d’un même team soient rattachées au même nœud NUMA.

La commande suivante permet de voir si vos carte d'un même team sont positionnées sur le même noeud NUMA.

 
Get-NetLbfoTeamMember -team [NOM DU TEAM]|get-NetAdapterRss |ft name,
numanode -auto
 

Si ce n'est pas le cas, vous devez définir le noeud sur leque doivent être positionnés vos cartes en fonction du
mappage réalisé.

La commande suivante permet de définir le noeud numa de la carte.

 
Set-NetAdapter - Numanode [N° du noeud numa]

 
Merci à Hans Vredevoort pour ses conseils et son excellent article qui a inspiré cette série.

Vous aimerez peut-être aussi