NetScaler VPX

Support-Matrix und Nutzungsrichtlinien

Dieses Dokument listet die verschiedenen Hypervisoren und Funktionen auf, die auf einer NetScaler VPX-Instanz unterstützt werden. Das Dokument beschreibt auch deren Nutzungsrichtlinien und bekannte Einschränkungen.

VPX-Instanz auf XenServer

XenServer-Version SysID Leistungsbereich
8.2 unterstützt ab 13.0 64.x, 8.0, 7.6, 7.1 450000 10 Mbit/s bis 40 Gbit/s

VPX-Instanz auf VMware ESXi-Hypervisor

ESXi-Version ESXi-Veröffentlichungsdatum (JJJJ/MM/TT) ESXi-Build-Nummer NetScaler VPX-Version Leistungsbereich
ESXi 9.0.2 2026/01/20 25148076 13.1-61.x und höhere Builds 10 Mbit/s bis 100 Gbit/s


























ESXi 8.0 Update 3g 2025/07/29 24859861 13.1-58.x und höhere Builds
ESXi 8.0 Update 3f 2025/07/15 24784735 13.1-58.x und höhere Builds
ESXi 8.0 Update 3e 2025/04/10 24674464 13.1-58.x und höhere Builds
ESXi 8.0 Update 3d 2025/03/04 24585383 13.1-56.x und höhere Builds
ESXi 8.0 Update 3c 2025/01/23 24414501 13.1-55.x und höhere Builds
ESXi 8.0 Update 3b 2024/09/17 24280767 13.1-53.x und höhere Builds
ESXi 8.0 Update 3 2024/06/25 24022510 13.1-53.x und höhere Builds
ESXi 8.0 Update 2c 2024/05/21 23825572 13.1-53.x und höhere Builds
ESXi 8.0 Update 2b 2024/02/29 23305546 13.1–49.15 und 13.1-52.x und höhere Builds
ESXi 8.0 Update 2 2023/09/21 22380479 13.1-52.x und höhere Builds
ESXi 8.0 Update 1 2023/04/18 21495797 13.1-45.x und höhere Builds
ESXi 8.0c 2023/03/30 21493926 13.1-45.x und höhere Builds
ESXi 8.0 2022/10/11 20513097 13.1-42.x und höhere Builds
ESXi 7.0 Update 3w 2025/07/15 24784741 13.1-58.x und höhere Builds
ESXi 7.0 Update 3s 2025/03/04 24585291 13.1-55.x und höhere Builds
ESXi 7.0 Update 3r 2024/12/12 24411414 13.1-55.x und höhere Builds
ESXi 7.0 Update 3q 2024/05/21 23794027 13.1-53.x und höhere Builds
ESXi 7.0 Update 3p 2024/03/05 23307199 13.1-52.x und höhere Builds
ESXi 7.0 Update 3o 2023/09/28 22348816 13.1-51.x und höhere Builds
ESXi 7.0 Update 3n 2023/07/06 21930508 13.1-49.x und höhere Builds
ESXi 7.0 Update 3m 2023/05/03 21686933 13.1-48.x und höhere Builds
ESXi 7.0 Update 3i 2022/12/08 20842708 13.1-37.x und höhere Builds
ESXi 7.0 Update 3f 2022/07/12 20036589 13.1-33.x und höhere Builds
ESXi 7.0 Update 3d 2022/03/29 19482537 13.1-27.x und höhere Builds
ESXi 7.0 Update 3c 2022/01/27 19193900 13.1-21.x und höhere Builds
ESX 7.0 Update 2d 2021/09/14 18538813 13.1-9.x und höhere Builds
ESX 7.0 Update 2a 2021/04/29 17867351 13.1-4.x und höhere Builds

Hinweis:

Die Unterstützung jedes ESXi-Patches wird mit der in der vorhergehenden Tabelle angegebenen NetScaler VPX-Version validiert und gilt für alle höheren Builds der NetScaler VPX 13.1-Version.

VPX-Instanz auf Microsoft Hyper-V

Hyper-V-Version SysID NetScaler VPX-Version Leistungsbereich
2016, 2019 450020

ab 13.1-4.x 10 Mbit/s bis 3 Gbit/s

2022 13.1-58.x und höher
2025 13.1-60.x und höher

VPX-Instanz auf Azure Local

Komponente Unterstützte Versionen / Builds SysID
NetScaler VPX 13.1-61.x und später 450020
Azure Lokaler OS-Build 25398.1965, 26100.7171 und 20349.3692

Weitere Informationen zu Azure Local-Release-Versionen finden Sie in der Microsoft-Dokumentation.

VPX-Instanz auf Nutanix AHV

NetScaler VPX wird auf Nutanix AHV über die Citrix Ready-Partnerschaft unterstützt. Citrix Ready ist ein Technologiepartnerprogramm, das Software- und Hardwareanbietern hilft, ihre Produkte mit der NetScaler-Technologie für digitale Arbeitsbereiche, Netzwerke und Analysen zu entwickeln und zu integrieren.

Weitere Informationen zu einer Schritt-für-Schritt-Methode zur Bereitstellung einer NetScaler VPX-Instanz auf Nutanix AHV finden Sie unter Bereitstellen einer NetScaler VPX auf Nutanix AHV.

Support durch Drittanbieter:

Wenn Sie Probleme mit einer bestimmten Integration eines Drittanbieters (Nutanix AHV) in einer NetScaler®-Umgebung haben, eröffnen Sie einen Supportfall direkt beim Drittanbieter-Partner (Nutanix).

Wenn der Partner feststellt, dass das Problem bei NetScaler zu liegen scheint, kann der Partner den NetScaler-Support um weitere Unterstützung bitten. Eine engagierte technische Ressource der Partner arbeitet mit dem NetScaler-Supportteam zusammen, bis das Problem behoben ist.

VPX-Instanz auf generischem KVM

Generische KVM-Version SysID Leistungsbereich
RHEL 7.6, RHEL 8.0, RHEL 9.3 450070
10 Mbit/s bis 100 Gbit/s
Ubuntu 16.04, Ubuntu 18.04, Ubuntu 22.04

Wichtige Hinweise:

Beachten Sie die folgenden Punkte bei der Verwendung von KVM-Hypervisoren.

  • Die VPX-Instanz ist für die in Tabelle 1–4 genannten Hypervisor-Release-Versionen qualifiziert, nicht jedoch für Patch-Releases innerhalb einer Version. Es wird jedoch erwartet, dass die VPX-Instanz nahtlos mit Patch-Releases einer unterstützten Version funktioniert. Sollte dies nicht der Fall sein, eröffnen Sie einen Supportfall zur Fehlerbehebung und Diagnose.

  • Bevor Sie RHEL 7.6 verwenden, führen Sie die folgenden Schritte auf dem KVM-Host aus:
    1. Bearbeiten Sie /etc/default/grub und fügen Sie "kvm_intel.preemption_timer=0" zur Variablen GRUB_CMDLINE_LINUX hinzu.

    2. Generieren Sie grub.cfg mithilfe des Befehls "# grub2-mkconfig -o /boot/grub2/grub.cfg" neu.

    3. Starten Sie die Hostmaschine neu.

  • Bevor Sie Ubuntu 18.04 verwenden, führen Sie die folgenden Schritte auf dem KVM-Host aus:

    1. Bearbeiten Sie /etc/default/grub und fügen Sie "kvm_intel.preemption_timer=0" zur Variablen GRUB_CMDLINE_LINUX hinzu.
    2. Regenerieren Sie grub.cfg mit dem Befehl "# grub-mkconfig -o /boot/grub/grub.cfg “.
    3. Starten Sie die Hostmaschine neu.

VPX-Instanz in öffentlichen Clouds

Öffentliche Cloud SysID Leistungsbereich
AWS 450040 10 Mbit/s bis 30 Gbit/s
Azure 450020 10 Mbit/s bis 10 Gbit/s
GCP 450070 10 Mbit/s bis 10 Gbit/s

Auf Hypervisoren unterstützte VPX-Funktionen

Hypervisoren →
Funktionen ↓
VPX auf XenServer
VPX auf VMware ESX
VPX auf Microsoft Hyper-V
VPX auf generischem KVM
Schnittstellen → PV SR-IOV PV SR-IOV Emuliert PCI-Passthrough PV PV SR-IOV PCI-Passthrough
Multi-PE-Unterstützung Ja Ja Ja Ja Ja Ja Ja Ja Ja Ja
Clustering-Unterstützung Ja Ja¹ Ja Ja¹ Ja Ja Ja Ja Ja¹ Ja
VLAN-Tagging Ja Ja Ja Ja Ja Ja Ja (nur auf 2012R2) Ja Ja Ja
Erkennung von Link-Ereignissen/HAMon Nein² Ja³ Nein² Ja³ Nein² Ja³ Nein² Nein² Ja³ Ja³
Schnittstellenparameterkonfiguration Nein Nein Nein Nein Nein Ja Nein Nein Nein Ja
Statisches LA Ja² Ja³ Ja² Nein Ja² Ja³ Ja² Ja² Ja³ Ja³
LACP Nein Ja³ Ja² Nein Ja² Ja³ Nein Ja² Ja³ Ja³
Static CLAG Nein Nein Nein Nein Nein Nein Nein Nein Nein Nein
LACP CLAG Nein Nein Ja² Nein Ja² Ja³ Nein Ja² Ja³ Ja³
Hot-Plug Nein Nein Nein Nein Nein Nein Nein Nein Nein Nein

VPX-Funktionen, die in öffentlichen Clouds unterstützt werden

Öffentliche Clouds →
Funktionen ↓
VPX unter AWS
VPX unter Azure
VPX unter GCP
Multi-PE-Unterstützung Ja Ja Ja
Clustering-Unterstützung Nein Nein Nein
VLAN-Tagging Nein Nein Nein
Erkennung von Link-Ereignissen/HAMon Nein² Nein² Nein²
Schnittstellenparameterkonfiguration Nein Nein Nein
Statisches LA Nein Nein Nein
LACP Nein Nein Nein
Statisches CLAG Nein Nein Nein
LACP CLAG Nein Nein Nein
Hot-Plug Ja Nein Nein

Die hochgestellten Zahlen (1, 2, 3) in den beiden vorhergehenden Tabellen beziehen sich auf die folgenden Punkte mit entsprechender Nummerierung:

  1. Clustering-Unterstützung ist auf SRIOV für clientseitige und serverseitige Schnittstellen verfügbar, nicht jedoch für die Backplane.
  2. Schnittstellen-DOWN-Ereignisse werden in NetScaler VPX-Instanzen nicht aufgezeichnet.
  3. Bei Static LA kann der Datenverkehr weiterhin über die Schnittstelle gesendet werden, deren physischer Status DOWN ist.

Die folgenden Punkte gelten für die jeweiligen Funktionen, die in den beiden vorhergehenden Tabellen erfasst sind:

  • Bei LACP kennt das Peer-Gerät das Schnittstellen-DOWN-Ereignis basierend auf dem LACP-Timeout-Mechanismus.

    • Kurzes Timeout: 3 Sekunden
    • Langes Timeout: 90 Sekunden
  • Bei LACP dürfen Schnittstellen nicht über VMs hinweg geteilt werden.
  • Bei dynamischem Routing hängt die Konvergenzzeit vom Routing-Protokoll ab, da Link-Ereignisse nicht erkannt werden.
  • Die Funktionalität der überwachten statischen Route schlägt fehl, wenn Sie keine Monitore an statische Routen binden, da der Routenstatus vom VLAN-Status abhängt. Der VLAN-Status hängt vom Link-Status ab.
  • Eine teilweise Fehlererkennung findet bei Hochverfügbarkeit nicht statt, wenn ein Link-Fehler vorliegt. Eine Hochverfügbarkeits-Split-Brain-Bedingung kann auftreten, wenn ein Link-Fehler vorliegt.
    • Wenn ein Link-Ereignis (Deaktivieren, Aktivieren, Zurücksetzen) von einer VPX-Instanz generiert wird, ändert sich der physische Status des Links nicht. Bei statischem LA wird jeglicher vom Peer initiierte Datenverkehr auf der Instanz verworfen.
    • Damit die VLAN-Tagging-Funktion auf VMware ESX funktioniert, legen Sie die VLAN-ID der Portgruppe auf 1–4095 auf dem vSwitch des VMware ESX-Servers fest.
  • Hot-Plug wird auf VPX-Instanzen mit ENA-Schnittstellen nicht unterstützt, und das Verhalten der Instanzen kann unvorhersehbar sein, wenn Hot-Plugging versucht wird. Hot-Adding wird nur für PV- und SRIOV-Schnittstellen mit NetScaler auf AWS unterstützt.
  • Das Hot-Entfernen über die AWS-Webkonsole oder die AWS-CLI-Schnittstelle wird mit den PV-, SRIOV- und ENA-Schnittstellen für NetScaler nicht unterstützt. Das Verhalten der Instanzen kann unvorhersehbar sein, wenn das Hot-Entfernen versucht wird.

Unterstützte Browser

Informationen zu unterstützten Browsern für den Zugriff auf NetScaler GUI Versionen 14.1 und 13.1 finden Sie unter Kompatible Browser.

Unterstützte Prozessoren für NetScaler VPX™

Plattformen Intel-Prozessor AMD-Prozessor
Citrix Hypervisor Ja Nein
ESXi Hypervisor Ja Ja
Hyper-V Ja Nein
KVM Ja Nein
AWS Ja Ja
Azure Ja Ja
GCP Ja Ja

Unterstützte NICs für NetScaler VPX

Die folgende Tabelle listet die NICs auf, die auf einer VPX-Plattform oder in der Cloud unterstützt werden.

NICs →
Plattformen ↓
Mellanox CX-3
Mellanox CX-4
Mellanox CX-5
Intel 82599 SRIOV VF
Intel X710/X722/XL710 SRIOV VF
Intel X710/XL710/XXV710 PCI-Passthrough Mode
Citrix Hypervisor NA NA NA Ja Ja Nein
ESXi Hypervisor Nein Ja Nein Ja Nein Ja
Hyper-V NA NA NA Nein Nein Nein
KVM Nein Ja Ja Ja Ja Nein
AWS NA NA NA Ja NA NA
Azure Ja Ja Ja NA NA NA
GCP NA NA NA NA NA NA

Nutzungsrichtlinien

Beachten Sie die folgenden Nutzungsrichtlinien:

  • Wir empfehlen Ihnen, eine VPX-Instanz auf lokalen Festplatten des Servers oder auf SAN-basierten Speichervolumes bereitzustellen.

Siehe den Abschnitt VMware ESXi CPU Considerations im Dokument Performance Best Practices for VMware vSphere 6.5. Hier ist ein Auszug:

  • Es wird nicht empfohlen, dass virtuelle Maschinen mit hohem CPU-/Speicherbedarf auf einem Host oder Cluster laufen, der überbelegt ist.

  • In den meisten Umgebungen ermöglicht ESXi eine erhebliche CPU-Überbelegung, ohne die Leistung virtueller Maschinen zu beeinträchtigen. Auf einem Host können Sie mehr vCPUs ausführen, als die Gesamtzahl der physischen Prozessorkerne auf diesem Host beträgt.

  • Wenn ein ESXi-Host CPU-gesättigt ist, d.h. die virtuellen Maschinen und andere Lasten auf dem Host alle verfügbaren CPU-Ressourcen des Hosts beanspruchen, können latenzempfindliche Workloads möglicherweise nicht gut funktionieren. In diesem Fall möchten Sie möglicherweise die CPU-Last reduzieren, z.B. indem Sie einige virtuelle Maschinen ausschalten oder auf einen anderen Host migrieren (oder DRS erlauben, sie automatisch zu migrieren).

  • Citrix empfiehlt die neueste Hardware-Kompatibilitätsversion, um die neuesten Funktionssätze des ESXi-Hypervisors für die virtuelle Maschine zu nutzen. Weitere Informationen zur Hardware- und ESXi-Versionskompatibilität finden Sie in der VMware-Dokumentation.

  • Die NetScaler VPX ist eine latenzempfindliche, hochleistungsfähige virtuelle Appliance. Um die erwartete Leistung zu erbringen, erfordert die Appliance vCPU-Reservierung, Speicherreservierung und vCPU-Pinning auf dem Host. Außerdem muss Hyper-Threading auf dem Host deaktiviert sein. Wenn der Host diese Anforderungen nicht erfüllt, treten Probleme wie High-Availability-Failover, CPU-Spitzen innerhalb der VPX-Instanz, Trägheit beim Zugriff auf die VPX-CLI, Absturz des Pit-Boss-Daemons, Paketverluste und geringer Durchsatz auf.

Ein Hypervisor gilt als überprovisioniert, wenn eine der folgenden zwei Bedingungen erfüllt ist:

  • Die Gesamtzahl der auf dem Host bereitgestellten virtuellen Kerne (vCPU) ist größer als die Gesamtzahl der physischen Kerne (pCPUs).

  • Die Gesamtzahl der bereitgestellten VMs verbraucht mehr vCPUs als die Gesamtzahl der pCPUs.

    Wenn eine Instanz überprovisioniert ist, kann der Hypervisor die reservierten Ressourcen (wie CPU, Arbeitsspeicher und andere) für die Instanz aufgrund von Hypervisor-Planungs-Overheads, Fehlern oder Einschränkungen des Hypervisors möglicherweise nicht garantieren. Dieses Verhalten kann zu einem Mangel an CPU-Ressourcen für NetScaler führen und zu den im ersten Punkt unter Nutzungsrichtlinien genannten Problemen. Als Administratoren wird empfohlen, die Belegung auf dem Host zu reduzieren, sodass die Gesamtzahl der auf dem Host bereitgestellten vCPUs kleiner oder gleich der Gesamtzahl der pCPUs ist.

    Beispiel:

    Wenn für den ESX-Hypervisor der %RDY%-Parameter einer VPX-vCPU im esxtop-Befehlsausgabe größer als 0 ist, weist der ESX-Host Planungs-Overheads auf, die zu Latenzproblemen für die VPX-Instanz führen können.

    Reduzieren Sie in einer solchen Situation die Belegung auf dem Host, sodass %RDY% immer auf 0 zurückkehrt. Alternativ wenden Sie sich an den Hypervisor-Anbieter, um den Grund für die Nichteinhaltung der Ressourcenreservierung zu klären.

  • Hot-Adding wird nur für PV- und SRIOV-Schnittstellen mit NetScaler auf AWS unterstützt. VPX-Instanzen mit ENA-Schnittstellen unterstützen kein Hot-Plugging, und das Verhalten der Instanzen kann unvorhersehbar sein, wenn Hot-Plugging versucht wird.
  • Das Hot-Removing über die AWS-Webkonsole oder die AWS-CLI-Schnittstelle wird für NetScaler mit den PV-, SRIOV- und ENA-Schnittstellen nicht unterstützt. Das Verhalten der Instanzen kann unvorhersehbar sein, wenn Hot-Removal versucht wird.

Befehle zur Steuerung der CPU-Auslastung der Paket-Engine

Sie können zwei Befehle (set ns vpxparam und show ns vpxparam) verwenden, um das Verhalten der CPU-Auslastung der Paket-Engine (Nicht-Management) von VPX-Instanzen in Hypervisor- und Cloud-Umgebungen zu steuern:

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

    Erlauben Sie jeder VM, CPU-Ressourcen zu nutzen, die einer anderen VM zugewiesen wurden, aber nicht verwendet werden.

    Set ns vpxparam-Parameter:

    -cpuyield: Freigabe oder Nicht-Freigabe von zugewiesenen, aber ungenutzten CPU-Ressourcen.

    • YES: Erlaubt, dass zugewiesene, aber ungenutzte CPU-Ressourcen von einer anderen VM verwendet werden.

    • NO: Reserviert alle CPU-Ressourcen für die VM, der sie zugewiesen wurden. Diese Option zeigt einen höheren Prozentsatz in Hypervisor- und Cloud-Umgebungen für die VPX-CPU-Auslastung.

    • STANDARD: Nein.

    Hinweis:

    Auf allen NetScaler VPX-Plattformen beträgt die vCPU-Auslastung auf dem Hostsystem 100 Prozent. Geben Sie den Befehl set ns vpxparam –cpuyield YES ein, um diese Auslastung zu überschreiben.

    Wenn Sie die Clusterknoten auf „yield“ setzen möchten, müssen Sie die folgenden zusätzlichen Konfigurationen in CCO durchführen:

    • Wenn ein Cluster gebildet wird, kommen alle Knoten mit „yield=DEFAULT“ hoch.
    • Wenn ein Cluster mit Knoten gebildet wird, die bereits auf „yield=YES“ gesetzt sind, werden die Knoten mit dem „DEFAULT“-Yield zum Cluster hinzugefügt.

    Hinweis:

    Wenn Sie die Clusterknoten auf „yield=YES“ setzen möchten, können Sie dies nur nach der Clusterbildung konfigurieren, nicht davor.

    -masterclockcpu1: Sie können die Haupttaktquelle von CPU0 (Management-CPU) auf CPU1 verschieben. Dieser Parameter hat die folgenden Optionen:

    • YES: Ermöglicht der VM, die Haupttaktquelle von CPU0 auf CPU1 zu verschieben.

    • NO: Die VM verwendet CPU0 als Haupttaktquelle. Standardmäßig ist CPU0 die Haupttaktquelle.

  • show ns vpxparam

    Zeigen Sie die aktuellen vpxparam-Einstellungen an.

Weitere Referenzen