NetScaler VPX

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

October 17, 2024

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. To achieve the desired performance, first follow the recommendations in the VPX data sheet, and then further optimize it using the best practices provided in this document.

Instance NetScaler VPX sur des hyperviseurs VMware ESX

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

Recommended configuration on ESX hosts

To achieve high performance for VPX with E1000, VMXNET3, SR-IOV, and PCI passthrough network interfaces, follow these recommendations:

The total number of virtual CPUs (vCPUs) provisioned on the ESX host must be less than or equal to the total number of physical CPUs (pCPUs) on the ESX host.
Non-uniform Memory Access (NUMA) affinity and CPU affinity must be set for the ESX host to achieve good results.

– To find the NUMA affinity of a Vmnic, log in to the host locally or remotely, and type:
```
   #vsish -e get /net/pNics/vmnic7/properties | grep NUMA
   Device NUMA Node: 0
 
```
- To set NUMA and vCPU affinity for a VM, see VMware documentation.

NetScaler VPX avec interfaces réseau E1000

Perform the following settings on the VMware ESX host:

On the VMware ESX host, create two vNICs from one pNIC vSwitch. Plusieurs vNIC créent plusieurs threads de réception (Rx) sur l’hôte ESX. This increases the Rx throughput of the pNIC interface.
Enable VLANs on the vSwitch port group level for each vNIC that you have created.

To increase vNIC transmit (Tx) throughput, use a separate Tx thread in the ESX host per vNIC. Use the following ESX command:

For ESX version 5.5:

   esxcli system settings advanced set –o /Net/NetTxWorldlet –i
 <!--NeedCopy-->

For ESX version 6.0 onwards:

   esxcli system settings advanced set -o /Net/NetVMTxType –i 1
 <!--NeedCopy-->

To further increase the vNIC Tx throughput, use a separate Tx completion thread and Rx threads per device (NIC) queue. Use the following ESX command:
```
   esxcli system settings advanced set -o /Net/NetNetqRxQueueFeatPairEnable -i 0
 
```

Remarque :

Make sure that you reboot the VMware ESX host to apply the updated settings.

Two vNICs per pNIC deployment

The following is a sample topology and configuration commands for the Two vNICs per pNIC model of deployment that delivers better network performance.

Two vNICs per pNIC deployment

Exemple de configuration de NetScaler VPX :

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

On the client side, bind the SNIP (1.1.1.2) to network interface 1/1 and enable the VLAN tag mode.

   bind vlan 2 -ifnum 1/1 –tagged
   bind vlan 2 -IPAddress 1.1.1.2 255.255.255.0
 <!--NeedCopy-->

On the server side, bind the SNIP (2.2.2.2) to network interface 1/1 and enable the VLAN tag mode.

   bind vlan 3 -ifnum 1/2 –tagged
   bind vlan 3 -IPAddress 2.2.2.2 255.255.255.0
 <!--NeedCopy-->

Add an HTTP virtual server (1.1.1.100) and bind it to a 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 :

Make sure that you include the following two entries in the route table:

1.1.1.0/24 subnet with gateway pointing to SNIP 1.1.1.2

2.2.2.0/24 subnet with gateway pointing to SNIP 2.2.2.2

NetScaler VPX avec interfaces réseau VMXNET3

To achieve high performance for VPX with VMXNET3 network interfaces, do the following settings on the VMware ESX host:

Create two vNICs from one pNIC vSwitch. Multiple vNICs create multiple Rx threads in the ESX host. This increases the Rx throughput of the pNIC interface.
Enable VLANs on the vSwitch port group level for each vNIC that you have created.

To increase vNIC transmit (Tx) throughput, use a separate Tx thread in the ESX host per vNIC. Use the following ESX commands:

For ESX version 5.5:

   esxcli system settings advanced set –o /Net/NetTxWorldlet –i
 <!--NeedCopy-->

For ESX version 6.0 onwards:

    esxcli system settings advanced set -o /Net/NetVMTxType –i 1
  <!--NeedCopy-->

On the VMware ESX host, perform the following configuration:

On the VMware ESX host, create two vNICs from 1 pNIC vSwitch. Multiple vNICs create multiple Tx and Rx threads in the ESX host. This increases the Tx and Rx throughput of the pNIC interface.
Enable VLANs on the vSwitch port group level for each vNIC that you have created.
To increase Tx throughput of a vNIC, use a separate Tx completion thread and Rx threads per device (NIC) queue. Utilisez la commande suivante :
```
   esxcli system settings advanced set -o /Net/NetNetqRxQueueFeatPairEnable -i 0
 
```
Configure a VM to use one transmit thread per vNIC, by adding the following setting to the VM’s configuration:
```
   ethernetX.ctxPerDev = "1"
 
```
Configurez une machine virtuelle pour utiliser jusqu’à 8 threads de transmission par vNIC, en ajoutant le paramètre suivant à la configuration de la machine virtuelle :
```
   ethernetX.ctxPerDev = "3"
 
```
Remarque :

L’augmentation du nombre de 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 de définir les paramètres précédents.

Remarque :

Make sure that you reboot the VMware ESX host to apply the updated settings.

You can configure VMXNET3 as a Two vNICs per pNIC deployment. For more information, see Two vNICs per pNIC deployment.

Configuration de la prise en charge des files d’attente multiples et du flux RSS sur les appareils VMware ESX pour 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 sur 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 appareils VMXNET3.

Pré-requis :

Pour configurer jusqu’à 19 files d’attente Rx et Tx sur les appareils ESX pour VMXNET3, assurez-vous que les conditions préalables suivantes sont remplies :

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

Configurez 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 (X étant le nombre de cartes réseau virtuelles à configurer). Le nombre maximum 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 maximum de files d’attente prises en charge, dans les scénarios où le nombre de files d’attente est considéré comme un obstacle aux performances. Dans ces situations, nous recommandons d’augmenter progressivement le nombre de files d’attente. Par exemple, de 8 à 12, puis à 16, puis à 20, et ainsi de suite. Évaluez les performances à chaque réglage, plutôt que de les augmenter directement jusqu’à la limite maximale.

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

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

Consignes d’utilisation de l’hyperviseur VMware ESXi

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

Consultez la section Considérations relatives au processeur VMware ESXi dans le document Meilleures pratiques en matière de performances pour VMware vSphere 6.5. Voici un extrait :
Il n’est pas recommandé de déployer des machines virtuelles sollicitant beaucoup de CPU ou de mémoire sur un hôte ou un cluster surchargé.
Dans la plupart des environnements, ESXi permet des niveaux significatifs de surcharge du processeur sans affecter les performances des machines virtuelles. Sur un hôte, vous pouvez exécuter plus de processeurs virtuels que le nombre total de cœurs de processeur physiques de cet hôte.
Si un hôte ESXi devient saturé en processeur, 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 du processeur, par exemple, en éteignant certaines machines virtuelles ou en les migrant vers un autre hôte (ou en autorisant DRS à les migrer automatiquement).
NetScaler recommande d’utiliser la dernière version de compatibilité matérielle pour bénéficier des derniers ensembles de fonctionnalités de l’hyperviseur ESXi pour la machine virtuelle. Pour plus d’informations sur la compatibilité entre le matériel et les versions d’ESXi, consultez la documentation VMware.
Le NetScaler VPX est une appliance virtuelle haute performance sensible à la latence. Pour atteindre les performances attendues, l’appliance nécessite la réservation du processeur virtuel, la réservation de la mémoire et l’épinglage du processeur virtuel sur l’hôte. En outre, l’hyper thread 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 de processeur au sein de l’instance VPX
- Lenteur lors de l’accès à la CLI VPX
- Crash du démon Pit Boss
- Gouttes de paquets
- Débit faible
Un Hypervisor est considéré comme surapprovisionné 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 processeurs physiques.
  
  Si une instance est surapprovisionnée, il se peut que l’hyperviseur ne garantisse pas les ressources réservées (telles que le processeur, la mémoire et autres) pour l’instance en raison des surcharges de planification de l’hyperviseur, des bogues ou des limitations avec l’hyperviseur. Ce comportement peut entraîner un manque de ressources CPU pour NetScaler et peut entraîner les problèmes mentionnés au premier point de la section Directives d’utilisation. Nous recommandons aux administrateurs de réduire la location de l’hôte afin que le nombre total de processeurs virtuels provisionnés sur l’hôte soit inférieur ou égal au nombre total de processeurs virtuels.
  
  Exemple
  
  Pour l’hyperviseur ESX, si le paramètre %RDY% d’un processeur virtuel VPX est supérieur à 0 dans la sortie de commande esxtop, l’hôte ESX est réputé avoir des frais de planification, ce qui peut entraîner des problèmes liés à la latence pour l’instance VPX.
  
  Dans ce cas, réduisez la location sur l’hôte afin que %RDY% revienne toujours à 0. Vous pouvez également contacter le fournisseur de l’hyperviseur pour déterminer les raisons pour lesquelles la réservation de ressources n’a pas été honorée.

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

Vous pouvez utiliser deux commandes (set ns vpxparam et show ns vpxparam) pour contrôler le comportement d’utilisation du processeur 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)]

Autorisez chaque machine virtuelle à utiliser les ressources du processeur allouées à une autre machine virtuelle mais qui ne sont pas utilisées.

Paramètres Set ns vpxparam :

-cpuyield : libère ou ne libère pas des ressources CPU allouées mais inutilisées.
- OUI : autorise l’utilisation des ressources CPU allouées mais inutilisées par une autre machine virtuelle.
- NON : réservez toutes les ressources du processeur pour la machine virtuelle à 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 processeur VPX.
- DEFAULT : Non.
Remarque :

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

Si vous souhaitez définir les nœuds du cluster sur « rendement », 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 des nœuds déjà définis sur « Yield=YES », les nœuds sont ajoutés au cluster en utilisant le rendement « DEFAULT ».
Remarque :

Si vous souhaitez définir les nœuds du cluster sur « YIELD=YES », vous pouvez configurer uniquement après la formation du cluster, mais pas avant la formation du cluster.

-masterclockcpu1 : Vous pouvez déplacer la source d’horloge principale de CPU0 (CPU de gestion) vers CPU1. Ce paramètre a les options suivantes :
- OUI : Autorisez la machine virtuelle à déplacer la source d’horloge principale de CPU0 vers CPU1.
- NON : VM utilise CPU0 pour la source d’horloge principale. Par défaut, CPU0 est la principale source d’horloge.
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 paramètres configurables, ainsi que d’autres suggestions qui vous aideront à optimiser les performances de l’instance NetScaler VPX sur la plate-forme Linux-KVM.

Paramètres de performance pour KVM

Perform the following settings on the KVM host:

Find the NUMA domain of the NIC using the lstopo command:

Make sure that memory for the VPX and the CPU is pinned to the same location. In the following output, the 10G NIC “ens2” is tied to NUMA domain #1.

NUMA domain #1

Allocate the VPX memory from the NUMA domain.

The numactl command indicates the NUMA domain from which the memory is allocated. In the following output, around 10 GB RAM is allocated from NUMA node #0.

NUMA node #0

To change the NUMA node mapping, follow these steps.

Modifiez le .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 machine virtuelle avec les mappages de nœuds NUMA.
Mettez le VPX sous tension. Vérifiez ensuite la sortie de la numactl –hardware commande sur l’hôte pour voir les allocations de mémoire mises à jour pour le VPX.

Pin vCPUs of VPX to physical cores.

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 sur les cœurs physiques 8 à 11.
Pour afficher l’utilisation actuelle du PCPU, tapez la commande suivante :
```
   mpstat -P ALL 5
 
```
Dans cette sortie, 8 correspond au processeur de gestion et 9 à 11 aux moteurs de paquets.
Pour changer le vCPU en épinglage PCPU, il existe deux options.
- Modifiez-le au moment de 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 .xml fichier 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 machine virtuelle avec les mappages de nœuds NUMA à l’aide de la commande suivante :
    virsh define /etc/libvirt/qemu/ <VPX_name>.xml 
  5. Mettez le VPX sous tension. Vérifiez ensuite la sortie de la virsh vcpupin <VPX name> commande sur l’hôte pour voir l’épinglage du processeur mis à jour.

Eliminate host interrupt overhead.

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

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

Pour trouver les sorties de machine virtuelle effectuées par les machines virtuelles exécutant l’hôte, utilisez la kvm_stat commande.
```
   [root@localhost ~]# kvm_stat -1  | grep EXTERNAL
   kvm_exit(EXTERNAL_INTERRUPT)  1728349 27738
   [root@localhost ~]#
 
```
Une valeur supérieure 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. Tout ce qui dépasse cela peut indiquer qu’il existe un ou plusieurs vecteurs d’interruption d’hôte mappés sur le même pCPU.
Détectez les interruptions de l’hôte et migrez les interruptions de l’hôte.

Lorsque vous exécutez la concatenate commande pour le fichier « /proc/interrupts », elle affiche tous les mappages d’interruption de l’hôte. Si un ou plusieurs IRQ actifs sont mappés sur le même PCPU, le compteur correspondant est incrémenté.

Déplacez toutes les interruptions qui se chevauchent avec les processeurs de votre NetScaler VPX vers les processeurs non utilisé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ésactivez la balance IRQ.

Désactivez le démon d’équilibrage de l’IRQ, de sorte 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 beaucoup de compteurs.

NetScaler VPX avec interfaces réseau photovoltaïque

You can configure para-virtualization (PV), SR-IOV, and PCIe passthrough network interfaces as a Two vNICs per pNIC deployment. For more information, see Two vNICs per pNIC deployment.

For optimal performance of PV (virtio) interfaces, follow these steps:

Identifiez le domaine NUMA auquel appartient le slot/NIC PCIe.
La mémoire et le processeur virtuel du VPX doivent être épinglés au même domaine NUMA.
Le thread Vhost doit être lié aux processeurs du même domaine NUMA.

Bind the virtual host threads to the corresponding CPUs:

Une fois le trafic démarré, exécutez la top commande sur l’hôte.
Identifiez l’affinité du processus hôte virtuel (nommé sous le nom vhost-<pid-of-qemu>).
Liez 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 à l’aide de 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-->

Bind the QEMU process to the corresponding physical core:

Identifiez les cœurs physiques sur lesquels le processus QEMU est exécuté. Pour plus d’informations, reportez-vous à la sortie précédente.
Liez 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 interfaces réseau relais SR-IOV et Fortville PCIe

For optimal performance of the SR-IOV and Fortville PCIe passthrough network interfaces, follow these steps:

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

Sample VPX XML file for vCPU and memory pinning for 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 à optimiser les performances de l’instance NetScaler VPX sur les hyperviseurs Citrix.

Paramètres de performance pour Citrix Hypervisors

Find the NUMA domain of the NIC using the “xl” command:

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

Pin vCPUs of VPX to physical cores.

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

Check binding of vCPUs.

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

Allouez plus de 8 processeurs virtuels aux machines virtuelles NetScaler.

For configuring more than 8 vCPUs, run the following commands from the Citrix Hypervisor console:

  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

For optimal performance of the SR-IOV network interfaces, follow these steps:

Identify the NUMA domain to which the PCIe slot or NIC is tied to.
Épinglez la mémoire et le processeur virtuel du VPX au même domaine NUMA.
Liez le vCPU Domain-0 au processeur restant.

NetScaler VPX avec interfaces para-virtualisées

For optimal performance, two vNICs per pNIC and one vNIC per pNIC configurations are advised, as in other PV environments.

To achieve optimal performance of para-virtualized (netfront) interfaces, follow these steps:

Identifiez le domaine NUMA auquel appartient le slot PCIe ou la carte réseau.
Épinglez la mémoire et le processeur virtuel du VPX au même domaine NUMA.
Liez le vCPU Domain-0 au processeur restant du même domaine NUMA.
Épinglez les threads Rx/Tx hôtes de vNIC aux vCPU du domaine 0.

Pin host threads to Domain-0 vCPUs:

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

```
Dans l’exemple suivant, ces valeurs indiquent :
- vif5.0 - Les threads de la première interface allouée à VPX dans XenCenter (interface de gestion).
- vif5.1 - Les threads de la deuxième interface assignée à VPX, etc.

Épinglez les threads aux vCPU du 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 ce document est en anglais. Certains contenus de la documentation Cloud Software Group ont été traduits de façon automatique à des fins pratiques uniquement. Cloud Software Group n'exerce aucun contrôle sur le contenu traduit de façon automatique, qui peut contenir des erreurs, des imprécisions ou un langage inapproprié. Aucune garantie, explicite ou implicite, n'est fournie quant à l'exactitude, la fiabilité, la pertinence ou la justesse de toute traduction effectuée depuis l'anglais d'origine vers une autre langue, ou quant à la conformité de votre produit ou service Cloud Software Group à tout contenu traduit de façon automatique, et toute garantie fournie en vertu du contrat de licence de l'utilisateur final ou des conditions d'utilisation des services applicables, ou de tout autre accord avec Cloud Software Group, quant à la conformité du produit ou service à toute documentation ne s'applique pas dans la mesure où cette documentation a été traduite de façon automatique. Cloud Software Group ne pourra être tenu responsable de tout dommage ou problème dû à l'utilisation de contenu traduit de façon automatique.

Cela vous a-t-il été utile ?

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

October 17, 2024

Contributeur:

C C

October 17, 2024

Contributeur:

C C

Dans cet article

Instance NetScaler VPX sur des hyperviseurs VMware ESX
Consignes d’utilisation de l’hyperviseur VMware ESXi
Commandes pour contrôler l’utilisation du processeur du moteur de paquets
Instance NetScaler VPX sur la plateforme Linux-KVM
Instance NetScaler VPX sur Citrix Hypervisors

Cela vous a-t-il été utile ?