Partagez l'article

Connexion






Mot de passe oublié ?
Identifiant oublié ?
Pas encore inscrit ? Créer un compte

Up-coming events

There are no up-coming events

Hyper-V 2012 R2-optimisation réseau 2 PDF Imprimer Envoyer
Note des utilisateurs: / 17
MauvaisTrès bien 
Écrit par Cédric Bravo   

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

optimisation Reseau Hyper-V 2

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\BelowTenGigVmqEnabled

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


ShowVMQ

 

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
(LACP inclus)

Min Queues

Min Queues

Min Queues

Switch Independent

Min Queues

Sum of Queues

Sum of Queues

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 *

Get-NetadapterVMQ

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.

HyperVVirtualSwitchProcessor

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.

 

RssNumberOfQueue

 

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.

RSSArchitecture

 

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*.

LPDefaultmapping

*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.

LPOptimizedMapping1

 

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

LPOptimizedMapping2

#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.

LPOptimizedMapping3

#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.

 

   

Mise à jour le Lundi, 28 Décembre 2015 15:04
 
Bannière

Joomla! is Free Software released under the GNU/GPL License.