Matrice de prise en charge et directives d’utilisation

Ce document répertorie les différents hyperviseurs et fonctionnalités pris en charge sur une instance Citrix ADC VPX. Il décrit également leurs directives d’utilisation et leurs limites.

Tableau 1. Instance VPX sur Citrix Hypervisor

Tableau 2. Instance VPX sur serveur VMware ESXi

Les modèles VPX suivants avec 450010 (ID système) prennent en charge les versions de VMware ESX répertoriées dans le tableau.

Modèles VPX : VPX 10, VPX 25, VPX 200, VPX 1000, VPX 3000, VPX 5000, VPX 8000, VPX 10G, VPX 15G, VPX 25G, VPX 40G et VPX 100G.

| Version ESXi | Date de sortie d’ESXi au format (AAAA/MM/JJ) | Numéro de build ESXi | Version Citrix ADC VPX | | ————————- | ——————————————– | ——————– | ——————————— | | Mise à jour ESXi 7.0 3m | 2023/05/03 | 21686933 | Versions 12.1-65.x et supérieures | | Mise à jour 3f d’ESXi 7.0 | 2022/07/12 | 20036589 | Versions 12.1-65.x et supérieures | | Mise à jour d’ESXi 7.0 3d | 2022/03/29 | 19482537 | Versions 12.1-65.x et supérieures | | ESXi 7.0 update 2d | 2021/09/14 | 18538813 | Versions 12.1-63.x et supérieures | | ESXi 7.0 update 2a | 2021/04/29 | 17867351 | Versions 12.1-62.x et supérieures | | ESXi 6.7 P04 | 11/2020/19 | 17167734 | Versions 12.1-55.x et supérieures | | ESXi 6.7 P03 | 2020/08/20 | 16713306 | Versions 12.1-55.x et supérieures | | ESXi 6.5 GA | 11/2016/15 | 4564106 | Versions 12.1-55.x et supérieures | | ESXi 6.5 U1g | 2018/3/20 | 7967591 | Versions 12.1-55.x et supérieures |

Remarque :

Chaque prise en charge de correctif ESXi est validée sur la version Citrix ADC VPX spécifiée dans le tableau précédent et s’applique à toutes les versions supérieures de la version Citrix VPX 12.1.

Tableau 4. Instance VPX sur KVM générique

Instance VPX sur Nutanix AHV

NetScaler VPX est pris en charge sur Nutanix AHV dans le cadre du 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 les espaces de travail numériques, les réseaux et les analyses. 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 la méthode étape par étape permettant de déployer une instance NetScaler VPX sur Nutanix AHV, consultez Déploiement d’un NetScaler VPX sur Nutanix AHV.

Assistance par des tiers :

Si vous rencontrez des problèmes lors de l’intégration d’un tiers en particulier (Nutanix AHV) dans un environnement NetScaler, signalez un incident de support directement auprès du partenaire tiers (Nutanix).

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

Tableau 4. Instance VPX sur KVM générique

Remarque :

L’instance VPX est qualifiée pour les versions de version de l’Hypervisor mentionnées dans le tableau 1—4, et non pour les versions de correctifs dans une version. Toutefois, 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, consignez un dossier de support pour le dépannage et le débogage.

Tableau 5. Instance VPX sur AWS

Tableau 6. Instance VPX sur Azure

Tableau 7. Matrice des fonctionnalités VPX

• La prise en charge du clustering est disponible sur SRIOV pour les interfaces client et serveur et non pour le fond de panier.

• Les événements DOWN de l’interface ne sont pas enregistrés dans les instances Citrix ADC VPX.

• Pour LA statique, le trafic peut toujours être envoyé sur l’interface dont l’état physique est DOWN.

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

  • Délai d’expiration court : 3 secondes
  • Délai d’attente long : 90 secondes

• Pour LACP, les interfaces ne doivent pas être partagées 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 les moniteurs ne sont pas liés à des routes statiques puisque 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 haute disponibilité et de division du cerveau peut se produire en cas de défaillance de la liaison.

• 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 statique, tout trafic initié par le pair est supprimé sur l’instance.

• Pour que la fonctionnalité de balisage VLAN fonctionne, procédez comme suit :

  Sur VMware ESX, définissez l’ID VLAN du groupe de ports sur 1 à 4095 sur le vSwitch du serveur VMware ESX.

Tableau 8. Navigateurs pris en charge

Directives d’utilisation

Suivez ces instructions d’utilisation :

• Consultez la section Considérations relatives au processeur VMware ESXi dans le document Performance Best Practices for VMware vSphere 6.5. Voici un extrait :

  Il n’est pas recommandé que les machines virtuelles dont la demande en CPU/mémoire est élevée se trouvent sur un hôte/un cluster surchargé. Dans la plupart des environnements, ESXi autorise des niveaux importants de surutilisation du processeur (c’est-à-dire l’exécution de plus de vCPU sur un hôte que le nombre total de cœurs de processeur physiques dans cet hôte) sans impact sur les processeurs virtuels performances de la machine. Si un hôte ESXi devient saturé en CPU (c’est-à-dire que les machines virtuelles et autres charges sur l’hôte demandent (toutes les ressources CPU dont dispose l’hôte) les charges de travail sensibles à la latence peuvent ne pas fonctionner correctement. Dans ce cas, vous vous souhaiterez peut-être réduire la charge du processeur, par exemple en mettant hors tension 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.

• Le Citrix ADC VPX est un dispositif virtuel hautes performances sensible à la latence. Pour fournir les performances attendues, le dispositif 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, des problèmes tels qu’un basculement de haute disponibilité, un pic de CPU dans l’instance VPX, une lenteur dans l’accès à la CLI VPX, un blocage du démon pitboss, des pertes de paquets et un faible débit se produisent.

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

    Parfois, si une instance est surprovisionnée, l’hyperviseur peut ne pas être en mesure de garantir les ressources réservées (telles que le processeur, la mémoire et autres) pour l’instance en raison de surcharges de planification de l’hyperviseur ou de bogues ou de limitations avec l’hyperviseur. Cela peut entraîner un manque de ressources CPU pour Citrix ADC et peut conduire aux problèmes mentionnés dans le premier point sous Directives d’utilisation. En tant qu’administrateurs, il est recommandé de réduire la location 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 processeurs physiques.

    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 dit avoir des surcharges de planification, ce qui peut entraîner des problèmes de 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 trier 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 sur Citrix ADC.

• La suppression à chaud via la console Web AWS ou AWS CLI n’est pas prise en charge pour les interfaces PV et SRIOV sur Citrix ADC. Le comportement des instances peut être imprévisible si la suppression à chaud est tentée.

• 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 (non-gestion) des instances VPX dans les environnements hypervisés et cloud :

  • set ns vpxparam -cpuyield (OUI | NON | PAR DÉFAUT) Autoriser chaque machine virtuelle à utiliser des ressources CPU qui ont été 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 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 processeur VPX.

    • DEFAULT : Non.

    Remarque :

    Sur toutes les plates-formes Citrix ADC VPX, l’utilisation du processeur virtuel sur le système hôte est de 100 %. Tapez la commande set ns vpxparam –cpuyield YES pour remplacer 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 présentent « 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 à l’aide du rendement « DEFAULT ».

    Remarque :

    Si vous souhaitez définir les nœuds du cluster sur « yield=YES », vous ne pouvez effectuer les configurations appropriées qu’après la formation du cluster, mais pas avant sa formation.

  • afficher ns vpxparam Affichez les paramètres vpxparam actuels.