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

Instance VPX sur hyperviseur VMware ESXi

Remarque :

Le support de 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 versions ultérieures de NetScaler VPX 13.1.

Instance VPX sur Microsoft Hyper-V

Instance VPX sur Azure Local

Pour plus d’informations sur les versions d’Azure Local, consultez la documentation Microsoft.

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 être lié à NetScaler, il peut contacter le support NetScaler pour obtenir une assistance supplémentaire. Une ressource technique dédiée des partenaires collabore avec l’équipe de support NetScaler jusqu’à ce que le problème soit résolu.

Instance VPX sur KVM générique

Points à noter :

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

• L’instance VPX est qualifiée pour les versions d’hyperviseur mentionnées dans le tableau 1–4, et non pour les versions de correctifs au sein d’une version. Cependant, l’instance VPX est censée 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 dossier 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. Regénérez grub.cfg à l’aide de 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 à l’aide de la commande "# grub-mkconfig -o /boot/grub/grub.cfg “.
  3. Redémarrez la machine hôte.

Instance VPX sur les clouds publics

Fonctionnalités VPX prises en charge sur les hyperviseurs

Fonctionnalités VPX prises en charge sur les clouds publics

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

1. La prise en charge du 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 HORS SERVICE ne sont pas enregistrés dans les instances NetScaler VPX.
3. Pour le LA statique, le trafic peut toujours être envoyé sur l’interface dont l’état physique est HORS SERVICE.

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

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

  • Délai d’expiration court : 3 secondes
  • Délai d’expiration long : 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 liaison 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 de la liaison.
• La détection de défaillance partielle ne se produit pas en haute disponibilité en cas de défaillance de liaison. Une condition de cerveau divisé en haute disponibilité peut se produire en cas de défaillance de liaison.
  • Lorsqu’un événement de liaison (désactivation, activation, réinitialisation) est généré à partir d’une instance VPX, l’état physique de la liaison ne change pas. Pour le 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 branchement à chaud 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 branchement à chaud est tenté. L’ajout à chaud est pris en charge uniquement 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.

Navigateurs pris en charge

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™

Cartes réseau prises en charge pour NetScaler VPX

Le tableau suivant répertorie les cartes réseau prises en charge sur une plate-forme VPX ou dans le cloud.

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 du document Performance Best Practices for VMware vSphere 6.5. Voici un extrait :

• Il n’est pas recommandé que les machines virtuelles ayant une forte demande en CPU/mémoire résident sur un hôte ou un cluster surchargé.

• Dans la plupart des environnements, ESXi permet des niveaux significatifs de surallocation 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 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 risquent de 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 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, des problèmes tels que le basculement de haute disponibilité, les pics 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 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 VM provisionnées consomme plus de vCPU que le nombre total de pCPU.

  Si une instance est surprovisionné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 bogues ou de limitations de l’hyperviseur. Ce comportement peut entraîner un manque de ressources CPU pour NetScaler et pourrait conduire aux problèmes mentionnés au 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ées 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 de 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 effectuée.

• L’ajout à chaud est pris en charge uniquement pour les interfaces PV et SRIOV avec NetScaler sur AWS. Les instances VPX avec des interfaces ENA ne prennent pas en charge le branchement à chaud, et le comportement des instances peut être imprévisible si un branchement à chaud est tenté.
• La suppression à chaud, que ce soit 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)]

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

  Paramètres Set ns vpxparam :

  -cpuyield : Libérer ou ne pas libérer les ressources CPU allouées mais inutilisées.

  • YES : Permettre que les ressources CPU allouées mais inutilisé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 %. Saisissez 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 démarrent avec « 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 pouvez configurer uniquement après la formation du cluster et non avant la formation du cluster.

  -masterclockcpu1 : Vous pouvez déplacer la source d’horloge principale du CPU0 (CPU de gestion) vers le CPU1. Ce paramètre offre les options suivantes :

  • OUI : Permet à la VM de déplacer la source d’horloge principale du CPU0 vers le CPU1.

  • NON : La VM utilise le CPU0 comme source d’horloge principale. Par défaut, le CPU0 est la source d’horloge principale.

• show ns vpxparam

  Affichez les paramètres vpxparam actuels.

Autres références

• Pour les produits Citrix Ready, visitez le Citrix Ready Marketplace.

• Pour le support produit Citrix Ready, consultez la page des partenaires Citrix Ready.

• Pour les versions matérielles de VMware ESX, consultez Mise à niveau de VMware Tools.