Produktdokumentation
NetScaler VPX
Current Release 13.1 13.0

Support-Matrix und Nutzungsrichtlinien

August 8, 2025
Beitrag von: 
C

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 oder Citrix Hypervisor

Citrix Hypervisor-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 8.0 Update 3e 2025/04/10 24674464 13.1-58.x und höhere Builds 10 Mbit/s bis 100 Gbit/s






















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 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 Leistungsbereich
2016, 2019 450020 10 Mbit/s bis 3 Gbit/s

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 zur schrittweisen 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 Support-Vorfall 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 dedizierte technische Ressource von den Partnern arbeitet mit dem NetScaler-Support 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 den Tabellen 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. Falls dies nicht der Fall ist, eröffnen Sie einen Support-Fall zur Fehlerbehebung und zum Debugging.

  • 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 Variable GRUB_CMDLINE_LINUX hinzu.

    2. Generieren Sie grub.cfg mit dem Befehl "# 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 Variable GRUB_CMDLINE_LINUX hinzu.
    2. Generieren Sie grub.cfg mit dem Befehl "# grub-mkconfig -o /boot/grub/grub.cfg “ neu.
    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

VPX-Funktionen, die auf Hypervisoren unterstützt werden

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
Statische LA Ja² Ja³ Ja² Nein Ja² Ja³ Ja² Ja² Ja³ Ja³
LACP Nein Ja³ Ja² Nein Ja² Ja³ Nein Ja² Ja³ Ja³
Statische 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 → VPX auf AWS VPX auf Azure VPX auf GCP
^^Funktionen ↓ ^^ ^^ ^^
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
Statische LA Nein Nein Nein
LACP Nein Nein Nein
Statische 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. Interface-DOWN-Ereignisse werden in NetScaler VPX-Instanzen nicht aufgezeichnet.
  3. Bei statischer 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 aufgeführt sind:

  • Bei LACP erkennt das Peer-Gerät das Interface-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 gemeinsam genutzt 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 Teilausfallerkennung findet bei Hochverfügbarkeit nicht statt, wenn ein Link-Fehler vorliegt. Eine Split-Brain-Bedingung bei Hochverfügbarkeit 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 statischer LA wird jeglicher vom Peer initiierter Datenverkehr auf der Instanz verworfen.
    • Damit die VLAN-Tagging-Funktion auf VMware ESX funktioniert, setzen Sie die VLAN-ID der Portgruppe auf 1–4095 auf dem vSwitch des VMware ESX-Servers.
  • 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-Removing über die AWS-Webkonsole oder die AWS-CLI-Schnittstelle wird für die PV-, SRIOV- und ENA-Schnittstellen von NetScaler nicht unterstützt. Das Verhalten der Instanzen kann unvorhersehbar sein, wenn Hot-Removal 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 auf einer VPX-Plattform oder in der Cloud unterstützten NICs auf.

NICs → 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-Modus
^^Plattformen ↓ ^^ ^^ ^^ ^^ ^^ ^^
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-Überlegungen 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 ein erhebliches Maß an CPU-Überbelegung, ohne die Leistung der virtuellen Maschine 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 wird, d. h. die virtuellen Maschinen und andere Lasten auf dem Host alle verfügbaren CPU-Ressourcen des Hosts beanspruchen, funktionieren latenzempfindliche Workloads möglicherweise nicht gut. 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.

  • Der 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 Hochverfügbarkeits-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 für die Instanz reservierten Ressourcen (wie CPU, Speicher und andere) aufgrund von Hypervisor-Scheduling-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 die im ersten Punkt unter Nutzungsrichtlinien genannten Probleme verursachen. Als Administratoren wird Ihnen 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 beim ESX-Hypervisor der %RDY%-Parameter einer VPX-vCPU in der Ausgabe des Befehls esxtop größer als 0 ist, wird davon ausgegangen, dass der ESX-Host Scheduling-Overheads aufweist, die zu latenzbezogenen Problemen für die VPX-Instanz führen können.

    In einer solchen Situation reduzieren Sie 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 vorgenommenen 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 Hot-Plug nicht, 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 die PV-, SRIOV- und ENA-Schnittstellen von NetScaler 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 CPU-Nutzungsverhalten 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)]

    Ermöglicht jeder VM, CPU-Ressourcen zu nutzen, die einer anderen VM zugewiesen wurden, aber nicht verwendet werden.

    Parameter von Set ns vpxparam:

    -cpuyield: Freigabe oder Nicht-Freigabe zugewiesener, aber ungenutzter CPU-Ressourcen.

    • YES: Ermöglicht die Nutzung zugewiesener, aber ungenutzter CPU-Ressourcen durch eine andere VM.

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

    • DEFAULT: 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 Cluster-Knoten auf “yield” setzen möchten, müssen Sie die folgenden zusätzlichen Konfigurationen auf CCO vornehmen:

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

    Hinweis:

    Wenn Sie die Cluster-Knoten auf “yield=YES” setzen möchten, können Sie dies erst nach der Bildung des Clusters 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

    Zeigt die aktuellen vpxparam-Einstellungen an.

Weitere Referenzen

Support-Matrix und Nutzungsrichtlinien
August 8, 2025
Beitrag von: 
C
August 8, 2025
Beitrag von: 
C

In diesem Artikel

Feedback zur Site | Your privacy choices footer linkIhre Datenschutzauswahl | Datenschutz und rechtliche Bestimmungen | Cookie-Einstellungen | Einstellungen für die Zustimmung | docs.cloud.com
© 1999- Cloud Software Group, Inc. All rights reserved.