NetScaler VPX 14.1

Optimiser les performances de NetScaler VPX sur VMware ESX, Linux KVM et Citrix Hypervisors

June 8, 2026

Contributeur:

C C

Les performances de NetScaler VPX varient considérablement en fonction de l’hyperviseur, des ressources système allouées et des configurations de l’hôte. Pour atteindre les performances souhaitées, suivez d’abord les recommandations de la fiche technique VPX, puis optimisez-les davantage en utilisant les meilleures pratiques fournies dans ce document.

Instance NetScaler VPX sur les hyperviseurs VMware ESX

Cette section contient les détails des options et paramètres configurables, ainsi que d’autres suggestions qui vous aident à atteindre les performances optimales de l’instance NetScaler VPX sur les hyperviseurs VMware ESX.

Configuration recommandée sur les hôtes ESX

Pour atteindre des performances élevées pour VPX avec les interfaces réseau E1000, VMXNET3, SR-IOV et PCI passthrough, suivez ces recommandations :

Le nombre total de CPU virtuels (vCPU) provisionnés sur l’hôte ESX doit être inférieur ou égal au nombre total de CPU physiques (pCPU) sur l’hôte ESX.
L’affinité d’accès mémoire non uniforme (NUMA) et l’affinité CPU doivent être définies pour l’hôte ESX afin d’obtenir de bons résultats.

– Pour trouver l’affinité NUMA d’un Vmnic, connectez-vous à l’hôte localement ou à distance, et tapez :
```
 #vsish -e get /net/pNics/vmnic7/properties | grep NUMA
 Device NUMA Node: 0
 
```
- Pour définir l’affinité NUMA et vCPU pour une VM, consultez la documentation VMware.

NetScaler VPX avec interfaces réseau E1000

Effectuez les réglages suivants sur l’hôte VMware ESX :

Sur l’hôte VMware ESX, créez deux vNIC à partir d’un vSwitch pNIC. Plusieurs vNIC créent plusieurs threads de réception (Rx) dans l’hôte ESX. Cela augmente le débit Rx de l’interface pNIC.
Activez les VLAN au niveau du groupe de ports du vSwitch pour chaque vNIC que vous avez créé.
Pour augmenter le débit de transmission (Tx) du vNIC, utilisez un thread Tx distinct dans l’hôte ESX par vNIC. Utilisez la commande ESX suivante :
- Pour ESX version 5.5 :
```
 esxcli system settings advanced set –o /Net/NetTxWorldlet –i
 
```
- Pour ESX version 6.0 et ultérieure :
```
 esxcli system settings advanced set -o /Net/NetVMTxType –i 1
 
```
Pour augmenter davantage le débit Tx du vNIC, utilisez un thread de complétion Tx distinct et des threads Rx par file d’attente de périphérique (NIC). Utilisez la commande ESX suivante :
```
 esxcli system settings advanced set -o /Net/NetNetqRxQueueFeatPairEnable -i 0
 
```

Remarque :

Assurez-vous de redémarrer l’hôte VMware ESX pour appliquer les paramètres mis à jour.

Déploiement de deux vNIC par pNIC

Voici un exemple de topologie et de commandes de configuration pour le modèle de déploiement Deux vNIC par pNIC qui offre de meilleures performances réseau.

Déploiement de deux vNIC par pNIC

Exemple de configuration NetScaler VPX :

Pour réaliser le déploiement illustré dans la topologie d’exemple précédente, effectuez la configuration suivante sur l’instance NetScaler VPX :

Côté client, liez le SNIP (1.1.1.2) à l’interface réseau 1/1 et activez le mode de balisage VLAN.
```
 bind vlan 2 -ifnum 1/1 –tagged
 bind vlan 2 -IPAddress 1.1.1.2 255.255.255.0
 
```
Côté serveur, liez le SNIP (2.2.2.2) à l’interface réseau 1/1 et activez le mode de balisage VLAN.
```
 bind vlan 3 -ifnum 1/2 –tagged
 bind vlan 3 -IPAddress 2.2.2.2 255.255.255.0
 
```

Ajoutez un serveur virtuel HTTP (1.1.1.100) et liez-le à un service (2.2.2.100).

 add lb vserver v1 HTTP 1.1.1.100 80 -persistenceType NONE -Listenpolicy None -cltTimeout 180
 add service s1 2.2.2.100 HTTP 80 -gslb NONE -maxClient 0 -maxReq 0 -cip DISABLED -usip NO -useproxyport YES -sp ON -cltTimeout 180 -svrTimeout 360 -CKA NO -TCPB NO -CMP NO
 bind lb vserver v1 s1
 <!--NeedCopy-->

Remarque :

Assurez-vous d’inclure les deux entrées suivantes dans la table de routage :

Sous-réseau 1.1.1.0/24 avec une passerelle pointant vers le SNIP 1.1.1.2

Sous-réseau 2.2.2.0/24 avec une passerelle pointant vers le SNIP 2.2.2.2

NetScaler VPX avec des interfaces réseau VMXNET3

Pour obtenir des performances élevées pour VPX avec des interfaces réseau VMXNET3, effectuez les réglages suivants sur l’hôte VMware ESX :

Créez deux vNIC à partir d’un vSwitch pNIC. Plusieurs vNIC créent plusieurs threads Rx dans l’hôte ESX. Cela augmente le débit Rx de l’interface pNIC.
Activez les VLAN au niveau du groupe de ports du vSwitch pour chaque vNIC que vous avez créé.
Pour augmenter le débit de transmission (Tx) du vNIC, utilisez un thread Tx distinct dans l’hôte ESX par vNIC. Utilisez les commandes ESX suivantes :
- Pour la version ESX 5.5 :
```
 esxcli system settings advanced set –o /Net/NetTxWorldlet –i
 
```
- Pour la version ESX 6.0 et ultérieure :
```
  esxcli system settings advanced set -o /Net/NetVMTxType –i 1
  
```

Sur l’hôte VMware ESX, effectuez la configuration suivante :

Sur l’hôte VMware ESX, créez deux vNIC à partir d’un vSwitch pNIC. Plusieurs vNIC créent plusieurs threads Tx et Rx dans l’hôte ESX. Cela augmente le débit Tx et Rx de l’interface pNIC.
Activez les VLANs au niveau du groupe de ports du vSwitch pour chaque vNIC que vous avez créé.
Pour augmenter le débit Tx d’une vNIC, utilisez un thread de complétion Tx séparé et des threads Rx par file d’attente de périphérique (NIC). Utilisez la commande suivante :
```
 esxcli system settings advanced set -o /Net/NetNetqRxQueueFeatPairEnable -i 0
 
```
Configurez une VM pour utiliser un thread de transmission par vNIC, en ajoutant le paramètre suivant à la configuration de la VM :
```
 ethernetX.ctxPerDev = "1"
 
```
Configurez une VM pour utiliser jusqu’à 8 threads de transmission par vNIC, en ajoutant le paramètre suivant à la configuration de la VM :
```
 ethernetX.ctxPerDev = "3"
 
```
Remarque :

L’augmentation des threads de transmission par vNIC nécessite davantage de ressources CPU (jusqu’à 8) sur l’hôte ESX. Assurez-vous que des ressources CPU suffisantes sont disponibles avant d’appliquer les paramètres précédents.

Remarque :

Assurez-vous de redémarrer l’hôte VMware ESX pour appliquer les paramètres mis à jour.

Vous pouvez configurer VMXNET3 comme un déploiement Deux vNICs par pNIC. Pour plus d’informations, consultez Déploiement de deux vNICs par pNIC.

Configurer la prise en charge multi-file d’attente et RSS sur VMware ESX pour les périphériques VMXNET3

Par défaut, le périphérique VMXNET3 ne prend en charge que 8 files d’attente Rx et Tx. Lorsque le nombre de vCPU sur le VPX dépasse 8, le nombre de files d’attente Rx et Tx configurées pour une interface VMXNET3 passe à 1 par défaut. Vous pouvez configurer jusqu’à 19 files d’attente Rx et Tx pour les périphériques VMXNET3 en modifiant certaines configurations sur ESX. Cette option augmente les performances et la distribution uniforme des paquets entre les vCPU de l’instance VPX.

Remarque :

À partir de la version 13.1 build 48.x de NetScaler, le NetScaler VPX prend en charge jusqu’à 19 files d’attente Rx et Tx sur ESX pour les périphériques VMXNET3.

Prérequis :

Pour configurer jusqu’à 19 files d’attente Rx et Tx sur ESX pour les périphériques VMXNET3, assurez-vous que les prérequis suivants sont remplis :

La version de NetScaler VPX est 13.1 build 48.X et ultérieure.
NetScaler VPX est configuré avec une machine virtuelle de version matérielle 17 et ultérieure, prise en charge par VMware ESX 7.0 et ultérieur.

Configurer les interfaces VMXNET3 pour prendre en charge plus de 8 files d’attente Rx et Tx :

Ouvrez le fichier de configuration de la machine virtuelle (.vmx).
Spécifiez le nombre de files d’attente Rx et Tx en configurant les valeurs ethernetX.maxTxQueues et ethernetX.maxRxQueues (où X est le numéro des cartes réseau virtuelles à configurer). Le nombre maximal de files d’attente configurées ne doit pas être supérieur au nombre de vCPU de la machine virtuelle.

Remarque :

L’augmentation du nombre de files d’attente augmente également la surcharge du processeur sur l’hôte ESX. Par conséquent, assurez-vous que des ressources CPU suffisantes sont disponibles sur l’hôte ESX avant d’augmenter les files d’attente. Vous pouvez augmenter le nombre maximal de files d’attente prises en charge, dans les scénarios où le nombre de files d’attente est identifié comme un goulot d’étranglement pour les performances. Dans ces situations, nous vous recommandons d’augmenter le nombre de files d’attente progressivement. Par exemple, de 8 à 12, puis à 16, puis à 20, et ainsi de suite. Évaluez les performances à chaque réglage, plutôt que d’augmenter directement jusqu’à la limite maximale.

NetScaler VPX avec interfaces réseau SR-IOV et PCI passthrough

Pour obtenir des performances élevées pour NetScaler VPX avec les interfaces réseau SR-IOV et PCI passthrough, consultez Configuration recommandée sur les hôtes ESX.

Directives d’utilisation pour l’hyperviseur VMware ESXi

Nous vous recommandons de déployer une instance NetScaler VPX sur les disques locaux du serveur ou sur des volumes de stockage basés sur SAN.

Consultez la section Considérations relatives au CPU VMware ESXi dans le document Bonnes pratiques de performance pour VMware vSphere 6.5. Voici un extrait :
Il n’est pas recommandé de déployer des machines virtuelles avec une forte demande en CPU ou en mémoire sur un hôte ou un cluster surprovisionné.
Dans la plupart des environnements, ESXi permet des niveaux significatifs de surprovisionnement de CPU sans impacter les performances des machines virtuelles. Sur un hôte, vous pouvez exécuter plus de vCPU que le nombre total de cœurs de processeur physiques de cet hôte.
Si un hôte ESXi est saturé en CPU, c’est-à-dire que les machines virtuelles et les autres charges sur l’hôte exigent toutes les ressources CPU dont dispose l’hôte, les charges de travail sensibles à la latence risquent de ne pas fonctionner correctement. Dans ce cas, réduisez la charge CPU, par exemple, en éteignant certaines machines virtuelles ou en les migrant vers un autre hôte (ou en permettant à DRS de les migrer automatiquement).
NetScaler recommande d’utiliser la dernière version de compatibilité matérielle pour bénéficier des dernières fonctionnalités de l’hyperviseur ESXi pour la machine virtuelle. Pour plus d’informations sur la compatibilité matérielle et la version d’ESXi, consultez la documentation VMware.
Le NetScaler VPX est une appliance virtuelle haute performance et sensible à la latence. Pour offrir les performances attendues, l’appliance nécessite une réservation de vCPU, une réservation de mémoire et un épinglage de vCPU sur l’hôte. De plus, l’hyperthreading doit être désactivé sur l’hôte. Si l’hôte ne répond pas à ces exigences, les problèmes suivants peuvent survenir :
- Basculement haute disponibilité
- Pic d’utilisation du CPU au sein de l’instance VPX
- Lenteur lors de l’accès à l’interface CLI du VPX
- Plantage du démon Pit Boss
- Pertes de paquets
- Faible débit
Un hyperviseur est considéré comme surprovisionné si l’une des deux conditions suivantes est remplie :
- Le nombre total de cœurs virtuels (vCPU) provisionnés sur l’hôte est supérieur au nombre total de cœurs physiques (pCPU).
- Le nombre total de machines virtuelles provisionnées consomme plus de vCPU que le nombre total de pCPU.
  
  Si une instance est surprovisionnée, l’hyperviseur peut ne pas garantir les ressources réservées (telles que le CPU, la mémoire et autres) pour l’instance en raison des surcharges de planification de l’hyperviseur, de bogues ou de limitations de l’hyperviseur. Ce comportement peut entraîner un manque de ressources CPU pour NetScaler et peut conduire aux problèmes mentionnés dans le premier point sous Directives d’utilisation. Nous recommandons aux administrateurs de réduire la charge de l’hôte afin que le nombre total de vCPU provisionnés sur l’hôte soit inférieur ou égal au nombre total de pCPU.
  
  Exemple :
  
  Pour l’hyperviseur ESX, si le paramètre %RDY% d’un vCPU VPX est supérieur à 0 dans la sortie de la commande esxtop, l’hôte ESX est considéré comme ayant des surcharges de planification, ce qui peut entraîner des problèmes liés à la latence pour l’instance VPX.
  
  Dans une telle situation, réduisez la charge sur l’hôte afin que %RDY% revienne toujours à 0. Alternativement, contactez le fournisseur de l’hyperviseur pour identifier la raison du non-respect de la réservation de ressources.

Commandes pour contrôler l’utilisation du CPU du moteur de paquets

Vous pouvez utiliser deux commandes (set ns vpxparam et show ns vpxparam) pour contrôler le comportement d’utilisation du CPU du moteur de paquets (hors gestion) des instances VPX dans les environnements d’hyperviseur et de cloud :

set ns vpxparam [-cpuyield (YES | NO | DEFAULT)] [-masterclockcpu1 (YES | NO)]

Permettre à chaque VM d’utiliser les ressources CPU allouées à une autre VM mais non utilisées.

Paramètres de Set ns vpxparam :

-cpuyield : Libérer ou ne pas libérer les ressources CPU allouées mais non utilisées.
- YES : Permettre que les ressources CPU allouées mais non utilisées soient utilisées par une autre VM.
- NO : Réserver toutes les ressources CPU pour la VM à laquelle elles ont été allouées. Cette option affiche un pourcentage plus élevé dans les environnements d’hyperviseur et de cloud pour l’utilisation du CPU VPX.
- DEFAULT : Non.
Remarque :

Sur toutes les plateformes NetScaler VPX, l’utilisation du vCPU sur le système hôte est de 100 pour cent. Utilisez la commande set ns vpxparam –cpuyield YES pour annuler cette utilisation.

Si vous souhaitez définir les nœuds du cluster sur “yield”, vous devez effectuer les configurations supplémentaires suivantes sur CCO :
- Si un cluster est formé, tous les nœuds sont définis sur “yield=DEFAULT”.
- Si un cluster est formé à l’aide de nœuds déjà définis sur “yield=YES”, les nœuds sont ajoutés au cluster en utilisant le “yield” “DEFAULT”.
Remarque :

Si vous souhaitez définir les nœuds du cluster sur « yield=YES », vous ne pouvez les configurer qu’après la formation du cluster, et non avant.

-masterclockcpu1 : Vous pouvez déplacer la source d’horloge principale du CPU0 (CPU de gestion) vers le CPU1. Ce paramètre a les options suivantes :
- YES : Permet à la VM de déplacer la source d’horloge principale du CPU0 vers le CPU1.
- NO : La VM utilise le CPU0 comme source d’horloge principale. Par défaut, le CPU0 est la source d’horloge principale.
show ns vpxparam

Cette commande affiche les paramètres vpxparam actuels.

Instance NetScaler VPX sur la plateforme Linux-KVM

Cette section contient des détails sur les options et les paramètres configurables, ainsi que d’autres suggestions qui vous aident à atteindre des performances optimales de l’instance NetScaler VPX sur la plateforme Linux-KVM.

Paramètres de performance pour KVM

Effectuez les réglages suivants sur l’hôte KVM :

Recherchez le domaine NUMA de la carte réseau à l’aide de la commande lstopo :

Assurez-vous que la mémoire pour le VPX et le CPU est épinglée au même emplacement. Dans la sortie suivante, la carte réseau 10G « ens2 » est liée au domaine NUMA #1.

Domaine NUMA #1

Allouer la mémoire VPX à partir du domaine NUMA.

La commande numactl indique le domaine NUMA à partir duquel la mémoire est allouée. Dans la sortie suivante, environ 10 Go de RAM sont alloués à partir du nœud NUMA #0.

Nœud NUMA #0

Pour modifier le mappage des nœuds NUMA, procédez comme suit.

Modifiez le fichier .xml du VPX sur l’hôte.

/etc/libvirt/qemu/<VPX_name>.xml
<!--NeedCopy-->

Ajoutez la balise suivante :

<numatune>
<memory mode="strict" nodeset="1"/>    This is the NUMA domain name
</numatune>
<!--NeedCopy-->

Arrêtez le VPX.
Exécutez la commande suivante :
```
virsh define /etc/libvirt/qemu/<VPX_name>.xml

```
Cette commande met à jour les informations de configuration de la VM avec les mappages de nœuds NUMA.
Mettez le VPX sous tension. Vérifiez ensuite la sortie de la commande numactl –hardware sur l’hôte pour voir les allocations de mémoire mises à jour pour le VPX.

Épingler les vCPU du VPX aux cœurs physiques.

Pour afficher les mappages vCPU vers pCPU d’un VPX, tapez la commande suivante
```
 virsh vcpupin <VPX name>
 
```
Les vCPU 0 à 4 sont mappés aux cœurs physiques 8 à 11.
Pour afficher l’utilisation actuelle du pCPU, tapez la commande suivante :
```
 mpstat -P ALL 5
 
```
Dans cette sortie, 8 est le CPU de gestion, et 9 à 11 sont les moteurs de paquets.
Pour modifier l’épinglage vCPU vers pCPU, il existe deux options.
- Modifiez-le à l’exécution après le démarrage du VPX à l’aide de la commande suivante :
```
 virsh vcpupin <VPX name> <vCPU id>  <pCPU number>
 virsh vcpupin NetScaler-VPX-XML 0 8
 virsh vcpupin NetScaler-VPX-XML 1 9
 virsh vcpupin NetScaler-VPX-XML 2 10
 virsh vcpupin NetScaler-VPX-XML 3 11
 
```
- Pour apporter des modifications statiques au VPX, modifiez le fichier .xml comme précédemment avec les balises suivantes :
  1. Modifiez le fichier .xml du VPX sur l’hôte
    /etc/libvirt/qemu/<VPX_name>.xml 
  2. Ajoutez la balise suivante :
    <vcpu placement='static' cpuset='8-11'>4</vcpu> <cputune> <vcpupin vcpu='0' cpuset='8'/> <vcpupin vcpu='1' cpuset='9'/> <vcpupin vcpu='2' cpuset='10'/> <vcpupin vcpu='3' cpuset='11'/> </cputune> 
  3. Arrêtez le VPX.
  4. Mettez à jour les informations de configuration de la VM avec les mappages de nœuds NUMA à l’aide de la commande suivante :
    virsh define /etc/libvirt/qemu/ <VPX_name>.xml 
  5. Allumez le VPX. Vérifiez ensuite la sortie de la commande virsh vcpupin <VPX name> sur l’hôte pour voir l’épinglage CPU mis à jour.

Éliminez la surcharge d’interruption de l’hôte.

Détectez les VM_EXITS à l’aide de la commande kvm_stat.

Au niveau de l’hyperviseur, les interruptions de l’hôte sont mappées aux mêmes pCPU sur lesquels les vCPU du VPX sont épinglés. Cela peut entraîner l’expulsion périodique des vCPU sur le VPX.

Pour trouver les sorties de VM effectuées par les VM exécutant l’hôte, utilisez la commande kvm_stat.
```
 [root@localhost ~]# kvm_stat -1  | grep EXTERNAL
 kvm_exit(EXTERNAL_INTERRUPT)  1728349 27738
 [root@localhost ~]#
 
```
Une valeur plus élevée de l’ordre de 1+M indique un problème.

Si une seule VM est présente, la valeur attendue est de 30 à 100 K. Toute valeur supérieure peut indiquer qu’un ou plusieurs vecteurs d’interruption de l’hôte sont mappés au même pCPU.
Détecter les interruptions de l’hôte et migrer les interruptions de l’hôte.

Lorsque vous exécutez la commande concatenate pour le fichier « /proc/interrupts », elle affiche tous les mappages d’interruption de l’hôte. Si une ou plusieurs IRQ actives sont mappées au même pCPU, son compteur correspondant s’incrémente.

Déplacez toutes les interruptions qui chevauchent les pCPU de votre NetScaler VPX vers des pCPU inutilisés :
```
 echo 0000000f > /proc/irq/55/smp_affinity
 0000000f - - > it is a bitmap, LSBs indicates that IRQ 55 can only be scheduled on pCPUs 0 – 3
 
```
Désactiver l’équilibrage IRQ.

Désactivez le démon d’équilibrage IRQ, afin qu’aucune replanification ne se produise à la volée.
```
 service irqbalance stop
 service irqbalance show - To check the status
 service irqbalance start - Enable if needed
 
```
Assurez-vous d’exécuter la commande kvm_stat pour vous assurer qu’il n’y a pas trop de compteurs.

NetScaler VPX avec interfaces réseau PV

Vous pouvez configurer des interfaces réseau de para-virtualisation (PV), SR-IOV et de passthrough PCIe en tant que déploiement Deux vNIC par pNIC. Pour plus d’informations, consultez Déploiement de deux vNIC par pNIC.

Pour des performances optimales des interfaces PV (virtio), suivez ces étapes :

Identifiez le domaine NUMA auquel appartient l’emplacement PCIe/NIC.
La mémoire et le vCPU pour le VPX doivent être épinglés au même domaine NUMA.
Le thread Vhost doit être lié aux CPU du même domaine NUMA.

Lier les threads de l’hôte virtuel aux CPU correspondants :

Une fois le trafic démarré, exécutez la commande top sur l’hôte.
Identifiez l’affinité du processus de l’hôte virtuel (nommé vhost-<pid-of-qemu>).
Lie les processus vHost aux cœurs physiques du domaine NUMA identifié précédemment à l’aide de la commande suivante :
```
taskset –pc <core-id> <process-id>

```
Exemple :
```
taskset –pc 12 29838

```

Les cœurs de processeur correspondant au domaine NUMA peuvent être identifiés avec la commande suivante :

[root@localhost ~]# virsh capabilities | grep cpu
<cpu>
    </cpu>
        <cpus num='8'>
            <cpu id='0' socket_id='0' core_id='0' siblings='0'/>
            <cpu id='1' socket_id='0' core_id='1' siblings='1'/>
            <cpu id='2' socket_id='0' core_id='2' siblings='2'/>
            <cpu id='3' socket_id='0' core_id='3' siblings='3'/>
            <cpu id='4' socket_id='0' core_id='4' siblings='4'/>
            <cpu id='5' socket_id='0' core_id='5' siblings='5'/>
            <cpu id='6' socket_id='0' core_id='6' siblings='6'/>
            <cpu id='7' socket_id='0' core_id='7' siblings='7'/>
        </cpus>

        <cpus num='8'>
        <cpu id='8' socket_id='1' core_id='0' siblings='8'/>
        <cpu id='9' socket_id='1' core_id='1' siblings='9'/>
        <cpu id='10' socket_id='1' core_id='2' siblings='10'/>
        <cpu id='11' socket_id='1' core_id='3' siblings='11'/>
        <cpu id='12' socket_id='1' core_id='4' siblings='12'/>
        <cpu id='13' socket_id='1' core_id='5' siblings='13'/>
        <cpu id='14' socket_id='1' core_id='6' siblings='14'/>
        <cpu id='15' socket_id='1' core_id='7' siblings='15'/>
        </cpus>

    <cpuselection/>
    <cpuselection/>

<!--NeedCopy-->

Lier le processus QEMU au cœur physique correspondant :

Identifiez les cœurs physiques sur lesquels le processus QEMU est en cours d’exécution. Pour plus d’informations, consultez la sortie précédente.
Lie le processus QEMU aux mêmes cœurs physiques auxquels vous liez les vCPU, à l’aide de la commande suivante :
```
taskset –pc 8-11 29824

```

NetScaler VPX avec SR-IOV et interfaces réseau de passthrough PCIe Fortville

Pour des performances optimales des interfaces réseau de passthrough PCIe SR-IOV et Fortville, suivez les étapes suivantes :

Identifiez le domaine NUMA auquel appartient le slot PCIe/NIC.
La mémoire et le vCPU pour NetScaler VPX doivent être épinglés au même domaine NUMA.

Exemple de fichier XML VPX pour l’épinglage du vCPU et de la mémoire pour Linux KVM :

    <domain type='kvm'>
        <name>NetScaler-VPX</name>
        <uuid>138f7782-1cd3-484b-8b6d-7604f35b14f4</uuid>
        <memory unit='KiB'>8097152</memory>
        <currentMemory unit='KiB'>8097152</currentMemory>
        <vcpu placement='static'>4</vcpu>

    <cputune>
        <vcpupin vcpu='0' cpuset='8'/>
        <vcpupin vcpu='1' cpuset='9'/>
        <vcpupin vcpu='2' cpuset='10'/>
        <vcpupin vcpu='3' cpuset='11'/>
    </cputune>

    <numatune>
    <memory mode='strict' nodeset='1'/>
    </numatune>

    </domain>
<!--NeedCopy-->

Instance NetScaler VPX sur Citrix Hypervisors

Cette section contient des détails sur les options et paramètres configurables, ainsi que d’autres suggestions qui vous aident à obtenir des performances optimales de l’instance NetScaler VPX sur Citrix Hypervisors.

Paramètres de performance pour Citrix Hypervisors

Trouver le domaine NUMA de la carte réseau à l’aide de la commande « xl » :

xl info -n
<!--NeedCopy-->

Épingler les vCPU du VPX aux cœurs physiques.

xl vcpu-pin <Netsclaer VM Name>  <vCPU id>  <physical CPU id>
<!--NeedCopy-->

Vérifier la liaison des vCPU.

xl vcpu-list
<!--NeedCopy-->

Allouer plus de 8 vCPU aux machines virtuelles NetScaler.

Pour configurer plus de 8 vCPU, exécutez les commandes suivantes depuis la console Citrix Hypervisor™ :

xe vm-param-set uuid=your_vms_uuid VCPUs-max=16
xe vm-param-set uuid=your_vms_uuid VCPUs-at-startup=16
<!--NeedCopy-->

NetScaler VPX avec interfaces réseau SR-IOV

Pour des performances optimales des interfaces réseau SR-IOV, suivez ces étapes :

Identifiez le domaine NUMA auquel l’emplacement PCIe ou la carte réseau est lié.
Épinglez la mémoire et le vCPU du VPX au même domaine NUMA.
Liez le vCPU du domaine 0 au CPU restant.

NetScaler VPX avec interfaces paravirtualisées

Pour des performances optimales, des configurations de deux vNIC par pNIC et d’un vNIC par pNIC sont conseillées, comme dans d’autres environnements PV.

Pour obtenir des performances optimales des interfaces paravirtualisées (netfront), suivez ces étapes :

Identifiez le domaine NUMA auquel appartient l’emplacement PCIe ou la carte réseau.
Épinglez la mémoire et le vCPU du VPX au même domaine NUMA.
Liez le vCPU du domaine 0 au CPU restant du même domaine NUMA.
Épinglez les threads Rx/Tx de l’hôte du vNIC aux vCPU du domaine 0.

Épingler les threads de l’hôte aux vCPU du domaine 0 :

Trouvez l’ID Xen de NetScaler VPX en utilisant la commande xl list sur le shell de l’hôte Citrix Hypervisor.
Identifiez les threads de l’hôte en utilisant la commande suivante :
```
ps -ax | grep vif <Xen-ID>

```
Dans l’exemple suivant, ces valeurs indiquent :
- vif5.0 - Les threads pour la première interface allouée au VPX dans XenCenter (interface de gestion).
- vif5.1 - Les threads pour la deuxième interface attribuée au VPX et ainsi de suite.

Épingler les threads aux vCPU de Domaine-0 à l’aide de la commande suivante :

taskset –pc <core-id> <process-id>
<!--NeedCopy-->

Exemple :

taskset -pc 1 29189
<!--NeedCopy-->

La version officielle de la documentation de ce produit est en anglais. Toute version dans une langue autre que l’anglais est fournie uniquement à titre indicatif et peut inclure du contenu traduit automatiquement. Pour en savoir plus, veuillez consulter la clause de non-responsabilité relative à la traduction automatique sur Cloud Software Group home.