NetScaler VPX

Matrice de support et directives d’utilisation

Ce document répertorie les différents hyperviseurs et fonctionnalités pris en charge sur une instance NetScaler VPX. Le document décrit également leurs directives d’utilisation et les limitations connues.

Instance VPX sur XenServer ou Citrix Hypervisor

Version de Citrix Hypervisor SysID Plage de performances
8.2 pris en charge à partir de 13.0 64.x, 8.0, 7.6, 7.1 450000 10 Mbit/s à 40 Gbit/s

Instance VPX sur l’hyperviseur VMware ESXi

Version ESXi Date de publication ESXi (AAAA/MM/JJ) Numéro de build ESXi Version NetScaler VPX Plage de performances
ESXi 8.0 update 3e 2025/04/10 24674464 13.1-58.x et builds supérieures 10 Mbit/s à 100 Gbit/s






















ESXi 8.0 update 3d 2025/03/04 24585383 13.1-56.x et builds supérieures
ESXi 8.0 update 3c 2025/01/23 24414501 13.1-55.x et builds supérieures
ESXi 8.0 update 3b 2024/09/17 24280767 13.1-53.x et builds supérieures
ESXi 8.0 update 3 2024/06/25 24022510 13.1-53.x et builds supérieures
ESXi 8.0 update 2c 2024/05/21 23825572 13.1-53.x et builds supérieures
ESXi 8.0 update 2b 2024/02/29 23305546 13.1-49.15, et 13.1-52.x et builds supérieures
ESXi 8.0 update 2 2023/09/21 22380479 13.1-52.x et builds supérieures
ESXi 8.0 update 1 2023/04/18 21495797 13.1-45.x et builds supérieures
ESXi 8.0c 2023/03/30 21493926 13.1-45.x et builds supérieures
ESXi 8.0 2022/10/11 20513097 13.1-42.x et builds supérieures
ESXi 7.0 update 3s 2025/03/04 24585291 13.1-55.x et builds supérieures
ESXi 7.0 update 3r 2024/12/12 24411414 13.1-55.x et builds supérieures
ESXi 7.0 update 3q 2024/05/21 23794027 13.1-53.x et builds supérieures
ESXi 7.0 update 3p 2024/03/05 23307199 13.1-52.x et builds supérieures
ESXi 7.0 update 3o 2023/09/28 22348816 13.1-51.x et builds supérieures
ESXi 7.0 update 3n 2023/07/06 21930508 13.1-49.x et builds supérieures
ESXi 7.0 update 3m 2023/05/03 21686933 13.1-48.x et builds supérieures
ESXi 7.0 update 3i 2022/12/08 20842708 13.1-37.x et builds supérieures
ESXi 7.0 update 3f 2022/07/12 20036589 13.1-33.x et builds supérieures
ESXi 7.0 update 3d 2022/03/29 19482537 13.1-27.x et builds supérieures
ESXi 7.0 update 3c 2022/01/27 19193900 13.1-21.x et builds supérieures
ESX 7.0 update 2d 2021/09/14 18538813 13.1-9.x et builds supérieures
ESX 7.0 update 2a 2021/04/29 17867351 13.1-4.x et builds supérieures

Remarque :

Chaque correctif ESXi est validé sur la version de NetScaler VPX spécifiée dans le tableau précédent et est applicable à toutes les builds supérieures de la version 13.1 de NetScaler VPX.

Instance VPX sur Microsoft Hyper-V

Version Hyper-V SysID Plage de performances
2016, 2019 450020 10 Mbit/s à 3 Gbit/s

Instance VPX sur Nutanix AHV

NetScaler VPX est pris en charge sur Nutanix AHV via le partenariat Citrix Ready. Citrix Ready est un programme de partenariat technologique qui aide les fournisseurs de logiciels et de matériel à développer et à intégrer leurs produits avec la technologie NetScaler pour l’espace de travail numérique, la mise en réseau et l’analyse.

Pour plus d’informations sur une méthode étape par étape pour déployer une instance NetScaler VPX sur Nutanix AHV, consultez Déploiement d’un NetScaler VPX sur Nutanix AHV.

Support tiers :

Si vous rencontrez des problèmes avec une intégration tierce (Nutanix AHV) particulière dans un environnement NetScaler, ouvrez un incident de support directement auprès du partenaire tiers (Nutanix).

Si le partenaire détermine que le problème semble provenir de NetScaler, le partenaire peut contacter le support NetScaler pour obtenir une assistance supplémentaire. Une ressource technique dédiée des partenaires travaille avec le support NetScaler jusqu’à ce que le problème soit résolu.

Instance VPX sur KVM générique

Version KVM générique SysID Plage de performances
RHEL 7.6, RHEL 8.0, RHEL 9.3 450070
10 Mbit/s à 100 Gbit/s
Ubuntu 16.04, Ubuntu 18.04, Ubuntu 22.04

Points à noter :

Tenez compte des points suivants lors de l’utilisation des hyperviseurs KVM.

  • L’instance VPX est qualifiée pour les versions de l’hyperviseur mentionnées dans les tableaux 1 à 4, et non pour les versions de correctifs au sein d’une version. Cependant, l’instance VPX devrait fonctionner de manière transparente avec les versions de correctifs d’une version prise en charge. Si ce n’est pas le cas, ouvrez un cas de support pour le dépannage et le débogage.

  • Avant d’utiliser RHEL 7.6, effectuez les étapes suivantes sur l’hôte KVM :
    1. Modifiez /etc/default/grub et ajoutez "kvm_intel.preemption_timer=0" à la variable GRUB_CMDLINE_LINUX.

    2. Régénérez grub.cfg avec la commande "# grub2-mkconfig -o /boot/grub2/grub.cfg".

    3. Redémarrez la machine hôte.

  • Avant d’utiliser Ubuntu 18.04, effectuez les étapes suivantes sur l’hôte KVM :

    1. Modifiez /etc/default/grub et ajoutez "kvm_intel.preemption_timer=0" à la variable GRUB_CMDLINE_LINUX.
    2. Régénérez grub.cfg avec la commande "# grub-mkconfig -o /boot/grub/grub.cfg “.
    3. Redémarrez la machine hôte.

Instance VPX sur les clouds publics

Cloud public SysID Plage de performances
AWS 450040 10 Mbit/s à 30 Gbit/s
Azure 450020 10 Mbit/s à 10 Gbit/s
GCP 450070 10 Mbit/s à 10 Gbit/s

Fonctionnalités VPX prises en charge sur les hyperviseurs

Hyperviseurs → VPX sur XenServer VPX sur VMware ESX
^^Fonctionnalités ↓ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^
Interfaces → PV SR-IOV PV SR-IOV Émulé PCI Passthrough PV PV SR-IOV PCI Passthrough
Support Multi-PE Oui Oui Oui Oui Oui Oui Oui Oui Oui Oui
Support de clustering Oui Oui¹ Oui Oui¹ Oui Oui Oui Oui Oui¹ Oui
Marquage VLAN Oui Oui Oui Oui Oui Oui Oui (uniquement sur 2012R2) Oui Oui Oui
Détection des événements de lien/HAMon Non² Oui³ Non² Oui³ Non² Oui³ Non² Non² Oui³ Oui³
Configuration des paramètres d’interface Non Non Non Non Non Oui Non Non Non Oui
LA statique Oui² Oui³ Oui² Non Oui² Oui³ Oui² Oui² Oui³ Oui³
LACP Non Oui³ Oui² Non Oui² Oui³ Non Oui² Oui³ Oui³
CLAG statique Non Non Non Non Non Non Non Non Non Non
LACP CLAG Non Non Oui² Non Oui² Oui³ Non Oui² Oui³ Oui³
Hot-plug Non Non Non Non Non Non Non Non Non Non

Fonctionnalités VPX prises en charge sur les clouds publics

Clouds publics → VPX sur AWS VPX sur Azure VPX sur GCP
^^Fonctionnalités ↓ ^^ ^^ ^^
Support Multi-PE Oui Oui Oui
Support de clustering Non Non Non
Marquage VLAN Non Non Non
Détection des événements de lien/HAMon Non² Non² Non²
Configuration des paramètres d’interface Non Non Non
LA statique Non Non Non
LACP Non Non Non
CLAG statique Non Non Non
LACP CLAG Non Non Non
Hot-plug Oui Non Non

Les numéros en exposant (1, 2, 3) utilisés dans les deux tableaux précédents se réfèrent aux points suivants avec la numérotation respective :

  1. Le support de clustering est disponible sur SRIOV pour les interfaces côté client et côté serveur, et non pour le fond de panier.
  2. Les événements d’interface DOWN ne sont pas enregistrés dans les instances NetScaler VPX.
  3. Pour la LA statique, le trafic peut toujours être envoyé sur l’interface dont l’état physique est DOWN.

Les points suivants s’appliquent aux fonctionnalités respectives capturées dans les deux tableaux précédents :

  • Pour LACP, le périphérique pair connaît l’événement DOWN de l’interface en fonction du mécanisme de temporisation LACP.

    • Temporisation courte : 3 secondes
    • Temporisation longue : 90 secondes
  • Pour LACP, ne partagez pas les interfaces entre les machines virtuelles.
  • Pour le routage dynamique, le temps de convergence dépend du protocole de routage car les événements de lien ne sont pas détectés.
  • La fonctionnalité de route statique surveillée échoue si vous ne liez pas de moniteurs aux routes statiques, car l’état de la route dépend de l’état du VLAN. L’état du VLAN dépend de l’état du lien.
  • La détection de défaillance partielle ne se produit pas en haute disponibilité en cas de défaillance de lien. Une condition de cerveau divisé en haute disponibilité peut se produire en cas de défaillance de lien.
    • Lorsqu’un événement de lien (désactiver, activer, réinitialiser) est généré à partir d’une instance VPX, l’état physique du lien ne change pas. Pour la LA statique, tout trafic initié par le pair est abandonné sur l’instance.
    • Pour que la fonctionnalité de marquage VLAN fonctionne sur VMware ESX, définissez l’ID VLAN du groupe de ports sur 1 à 4095 sur le vSwitch du serveur VMware ESX.
  • Le hot-plug n’est pas pris en charge sur les instances VPX avec des interfaces ENA, et le comportement des instances peut être imprévisible si un hot-plug est tenté. L’ajout à chaud n’est pris en charge que pour les interfaces PV et SRIOV avec NetScaler sur AWS.
  • La suppression à chaud via la console Web AWS ou l’interface CLI AWS n’est pas prise en charge avec les interfaces PV, SRIOV et ENA pour NetScaler. Le comportement des instances peut être imprévisible si une suppression à chaud est tentée.

Pour plus d’informations sur les navigateurs pris en charge pour l’accès aux versions 14.1 et 13.1 de l’interface graphique de NetScaler, consultez Navigateurs compatibles.

Processeurs pris en charge pour NetScaler VPX

Plateformes Processeur Intel Processeur AMD
Citrix Hypervisor Oui Non
ESXi Hypervisor Oui Oui
Hyper-V Oui Non
KVM Oui Non
AWS Oui Oui
Azure Oui Oui
GCP Oui Oui

Cartes réseau prises en charge pour NetScaler VPX

Le tableau suivant répertorie les cartes réseau prises en charge sur une plateforme VPX ou un cloud.

Cartes réseau → Mellanox CX-3 Mellanox CX-4 Mellanox CX-5 Intel 82599 SRIOV VF Intel X710/X722/XL710 SRIOV VF Intel X710/XL710/XXV710 Mode PCI-Passthrough
^^Plateformes ↓ ^^ ^^ ^^ ^^ ^^ ^^
Citrix Hypervisor NA NA NA Oui Oui Non
ESXi Hypervisor Non Oui Non Oui Non Oui
Hyper-V NA NA NA Non Non Non
KVM Non Oui Oui Oui Oui Non
AWS NA NA NA Oui NA NA
Azure Oui Oui Oui NA NA NA
GCP NA NA NA NA NA NA

Directives d’utilisation

Suivez ces directives d’utilisation :

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

Consultez la section VMware ESXi CPU Considerations dans le document Performance Best Practices for VMware vSphere 6.5. Voici un extrait :

  • Il n’est pas recommandé que les machines virtuelles ayant des exigences élevées en CPU/mémoire résident sur un hôte ou un cluster sur-engagé.

  • Dans la plupart des environnements, ESXi permet des niveaux significatifs de sur-engagement du 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 devient 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 pourraient ne pas fonctionner correctement. Dans ce cas, vous pourriez vouloir réduire 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).

  • Citrix recommande 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 ESXi, consultez la documentation VMware.

  • NetScaler VPX est une appliance virtuelle sensible à la latence et haute performance. Pour offrir les performances attendues, l’appliance nécessite une réservation de vCPU, une réservation de mémoire, 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, des problèmes tels que le basculement de haute disponibilité, le pic de CPU au sein de l’instance VPX, la lenteur d’accès à l’interface CLI VPX, le crash du démon pit boss, les pertes de paquets et un faible débit se produisent.

Un hyperviseur est considéré comme sur-provisionné 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 sur-provisionnée, l’hyperviseur pourrait 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 bugs 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. En tant qu’administrateurs, il vous est recommandé de réduire la charge sur 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 analyser la raison du non-respect de la réservation de ressources effectuée.

  • L’ajout à chaud n’est pris en charge que pour les interfaces PV et SRIOV avec NetScaler sur AWS. Les instances VPX avec des interfaces ENA ne prennent pas en charge le hot-plug, et le comportement des instances peut être imprévisible si un hot-plug est tenté.
  • La suppression à chaud via la console Web AWS ou l’interface CLI AWS n’est pas prise en charge avec les interfaces PV, SRIOV et ENA pour NetScaler. Le comportement des instances peut être imprévisible si une suppression à chaud est tentée.

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 (non-gestion) des instances VPX dans les environnements d’hyperviseur et de cloud :

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

    Permet à chaque machine virtuelle d’utiliser les ressources CPU qui ont été allouées à une autre machine virtuelle mais qui ne sont pas utilisées.

    Paramètres de Set ns vpxparam :

    -cpuyield : Libérer ou non les ressources CPU allouées mais inutilisées.

    • YES : Permet aux ressources CPU allouées mais inutilisées d’être utilisées par une autre machine virtuelle.

    • NO : Réserve toutes les ressources CPU 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 CPU VPX.

    • DEFAULT : Non.

    Remarque :

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

    Si vous souhaitez définir les nœuds de cluster sur “yield”, vous devez effectuer les configurations supplémentaires suivantes sur CCO :

    • Si un cluster est formé, tous les nœuds démarrent avec “yield=DEFAULT”.
    • Si un cluster est formé en utilisant les nœuds déjà définis sur “yield=YES”, alors les nœuds sont ajoutés au cluster en utilisant le “DEFAULT” yield.

    Remarque :

    Si vous souhaitez définir les nœuds de 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 machine virtuelle de déplacer la source d’horloge principale du CPU0 vers le CPU1.

    • NO : La machine virtuelle utilise le CPU0 comme source d’horloge principale. Par défaut, le CPU0 est la source d’horloge principale.

  • show ns vpxparam

    Affiche les paramètres vpxparam actuels.

Autres références