Produktdokumentation
ADC
14.1 - Current Release 13.1 13.0 12.1
PDF anzeigen

Support-Matrix und Nutzungsrichtlinien

August 6, 2024
Beitrag von: 
C

In diesem Dokument werden die verschiedenen Hypervisoren und Funktionen aufgeführt, die auf einer NetScaler VPX-Instanz unterstützt werden. Das Dokument beschreibt auch ihre Nutzungsrichtlinien und bekannten Einschränkungen.

VPX-Instanz auf Citrix Hypervisor

Citrix Hypervisor Version SysID VPX Modelle
8.2 unterstützt ab 13.0 64.x, 8.0, 7.6, 7.1 450000 VPX 10, VPX 25, VPX 200, VPX 1000, VPX 3000, VPX 5000, VPX 8000, VPX 10G, VPX 15G, VPX 25G, VPX 40G

VPX-Instanz auf dem VMware ESXi-Hypervisor

Die folgenden VPX-Modelle mit 450010 (Sys ID) unterstützen die in der Tabelle aufgeführten VMware ESX-Versionen.

VPX-Modelle: VPX 10, VPX 25, VPX 200, VPX 1000, VPX 3000, VPX 5000, VPX 8000, VPX 10G, VPX 15G, VPX 25G, VPX 40G und VPX 100G.

ESXi-Version ESXi-Veröffentlichungsdatum (YYYY/MM/DD) ESXi-Build-Nummer NetScaler VPX Version
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-Aktualisierung 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 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 Aktualisierung 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 Versionen 13.1-33.x und höher
ESXi 7.0-Update 3d 2022/03/29 19482537 Versionen 13.1-27.x und höher
ESXi 7.0 3c aktualisieren 2022/01/27 19193900 Versionen 13.1-21.x und höher
ESX 7.0-Update 2d 2021/09/14 18538813 Versionen 13.1-9.x und höher
ESX 7.0 Update 2a 2021/04/29 17867351 13.1-4.x und höhere Builds

Hinweis:

Jede ESXi-Patchunterstützung wird für die in der obigen Tabelle angegebene 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 VPX Modelle
2016, 2019 450020 VPX 10, VPX 25, VPX 200, VPX 1000, VPX 3000

VPX-Instanz auf Nutanix AHV

NetScaler VPX wird auf Nutanix AHV durch die Citrix Ready-Partnerschaft unterstützt. Citrix Ready ist ein Technologiepartnerprogramm, das Software- und Hardwareanbieter bei der Entwicklung und Integration ihrer Produkte mit der NetScaler-Technologie für digitale Workspace, Netzwerke und Analysen unterstützt.

Weitere Informationen zu einer schrittweisen Methode zur Bereitstellung einer NetScaler VPX-Instanz auf Nutanix AHV finden Sie unter Deploying aNetScaler VPX auf Nutanix AHV.

Unterstützung durch Dritte:

Wenn Sie Probleme mit der Integration eines bestimmten Drittanbieters (Nutanix AHV) in einer NetScaler-Umgebung haben, wenden Sie sich direkt an den Drittanbieter-Partner (Nutanix).

Wenn der Partner feststellt, dass das Problem offenbar bei NetScaler liegt, kann er sich an den NetScaler-Support wenden, um weitere Unterstützung zu erhalten. Eine dedizierte technische Ressource von Partnern arbeitet mit dem NetScaler-Support zusammen, bis das Problem behoben ist.

Weitere Informationen finden Sie unter Häufig gestellte Fragen zum Citrix Ready-Partnerprogramm.

VPX-Instanz auf generischem KVM

Generische KVM-Version SysID VPX Modelle
RHEL 7.6, RHEL 8.0, RHEL 9.3 450070
VPX 10, VPX 25, VPX 200, VPX 1000, VPX 3000, VPX 5000, VPX 8000, VPX 10 G, VPX 15 G. VPX 25G, VPX 40G, VPX 100G
Ubuntu 16.04, Ubuntu 18.04, RHV 4.2

Zu beachtende Punkte:

Berücksichtigen Sie bei der Verwendung von KVM-Hypervisoren die folgenden Punkte.

  • Die VPX-Instanz ist für Hypervisor Releaseversionen in Tabelle 1−4 und nicht für Patch-Releases innerhalb einer Version qualifiziert. Es wird jedoch erwartet, dass die VPX-Instanz nahtlos mit Patch-Versionen einer unterstützten Version funktioniert. Wenn dies nicht der Fall ist, öffnen Sie einen Supportfall für die Fehlerbehebung und das Debuggen.

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

    1. Bearbeiten Sie /etc/default/grub und hängen Sie "kvm_intel.preemption_timer=0" an die Variable GRUB_CMDLINE_LINUX an.

    2. Generieren Sie grub.cfg mit dem Befehl "# grub2-mkconfig -o /boot/grub2/grub.cfg" neu.

    3. Starten Sie den Hostcomputer 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 hängen Sie "kvm_intel.preemption_timer=0" an die Variable GRUB_CMDLINE_LINUX an.
    2. Generieren Sie grub.cfg mit dem Befehl "# grub-mkconfig -o /boot/grub/grub.cfg “ neu.
    3. Starten Sie den Hostcomputer neu.

VPX-Instanz auf AWS

AWS-Version SysID VPX Modelle
– 450040 VPX 10, VPX 200, VPX 1000, VPX 3000, VPX 5000, VPX BYOL, VPX 8000, VPX 10G, VPX 15G und VPX 25G sind nur mit BYOL mit EC2-Instanztypen (C5, M5 und C5n) verfügbar

Hinweis:

Das VPX 25G-Angebot bietet nicht den 25G-Durchsatz in AWS, kann jedoch im Vergleich zum VPX 15G-Angebot eine höhere SSL-Transaktionsrate bieten.

VPX-Instanz auf Azure

Azure-Version SysID VPX Modelle
– 450020 VPX 10, VPX 200, VPX 1000, VPX 3000, VPX 5000, VPX BYOL

VPX-Funktionsmatrix

VPX-Merkmalmatrix-Tabelle

Die in der vorstehenden Tabelle verwendeten hochgestellten Zahlen (1, 2, 3) beziehen sich auf die folgenden Punkte mit entsprechender Nummerierung:

  1. Clustering-Unterstützung ist auf SRIOV für clientseitige und serverseitige Schnittstellen und nicht für die Rückwandplatine verfügbar.

  2. Interface DOWN Ereignisse werden in NetScaler VPX-Instanzen nicht aufgezeichnet.

  3. Für statische LA wird möglicherweise weiterhin Datenverkehr auf der Schnittstelle gesendet, deren physischer Status DOWN ist.

  4. Für LACP kennt das Peer-Gerät das Interface DOWN-Ereignis basierend auf dem LACP-Timeout-Mechanismus.

    • Kurzes Timeout: 3 Sekunden
    • Langes Timeout: 90 Sekunden

  5. Teilen Sie für LACP keine Schnittstellen zwischen VMs.

  6. Bei dynamischem Routing hängt die Konvergenzzeit vom Routingprotokoll ab, da Linkereignisse nicht erkannt werden.

  7. Die überwachte statische Route-Funktionalität 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 Verbindungsstatus ab.

  8. Eine teilweise Fehlererkennung erfolgt bei hoher Verfügbarkeit nicht, wenn ein Verbindungsfehler vorliegt. Eine Hohe-Verfügbarkeit-Split-Brain-Bedingung kann auftreten, wenn ein Verbindungsfehler vorliegt.

    • Wenn ein Linkereignis (Deaktivieren/Aktivieren, Zurücksetzen) von einer VPX-Instanz generiert wird, ändert sich der physische Status des Links nicht. Bei statischer LA wird jeder vom Peer initiierte Datenverkehr auf der Instanz gelöscht.

    • Damit die VLAN-Tagging-Funktion funktioniert, gehen Sie folgendermaßen vor:

    Legen Sie auf VMware ESX die VLAN-ID der Portgruppe auf dem vSwitch des VMware ESX-Servers auf 1-4095 fest. Weitere Informationen zum Festlegen einer VLAN-ID auf dem vSwitch des VMware ESX-Servers finden Sie unter VMware ESX Server 3 802.1Q VLAN Solutions.

Unterstützte Browser

Betriebssystem Browser und Versionen
Windows 7 Internet Explorer-8, 9, 10 und 11; Mozilla Firefox 3.6.25 und höher; Google Chrome-15 und höher
Windows 64-Bit Internet Explorer − 8, 9; Google Chrome − 15 und höher
MAC Mozilla Firefox - 12 und höher; Safari - 5.1.3; Google Chrome - 15 und höher

AMD-Prozessorunterstützung für VPX-Instanzen

Ab NetScaler Version 13.1 unterstützt die VPX-Instanz sowohl die Intel- als auch die AMD-Prozessoren. Virtuelle VPX-Appliances können auf jedem Instanztyp bereitgestellt werden, der über zwei oder mehr virtualisierte Kerne und mehr als 2 GB Arbeitsspeicher verfügt. Weitere Informationen zu den Systemanforderungen finden Sie unter Datenblatt zu NetScaler VPX.

VPX-Plattformen im Vergleich zu NIC-Matrixtabelle

In der folgenden Tabelle sind die Netzwerkkarten aufgeführt, die auf einer VPX-Plattform oder Cloud unterstützt werden.

Mellanox CX-3 Mellanox CX-4 Mellanox CX-5 Intel 82599 SRIOV VF Intel X710/X722/XL710 SRIOV VF Intel X710/XL710 PCI-Passthrough-Modus
  VPX (ESXi) Nein Ja Nein Ja Nein Ja
  VPX (Citrix Hypervisor) Nicht verfügbar Nicht verfügbar Nicht verfügbar Ja Ja Nein
  VPX (KVM) Nein Ja Ja Ja Ja Ja
  VPX (Hyper-V) Nicht verfügbar Nicht verfügbar Nicht verfügbar Nein Nein Nein
  VPX (AWS) Nicht verfügbar Nicht verfügbar Nicht verfügbar Ja Nicht verfügbar Nicht verfügbar
  VPX (Azure) Ja Ja Ja Nicht verfügbar Nicht verfügbar Nicht verfügbar
  VPX (GCP) Nicht verfügbar Nicht verfügbar Nicht verfügbar Nicht verfügbar Nicht verfügbar Nicht verfügbar

Richtlinien für die Verwendung

Folgen Sie diesen Nutzungsrichtlinien:

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

Weitere Informationen finden Sie im Abschnitt VMware ESXi CPU Considerations im Dokument Performance Best Practices for VMware vSphere 6.5. Hier ist ein Auszug:

  • Es wird nicht empfohlen, virtuelle Maschinen mit hohem CPU-/Speicherbedarf auf einem Host oder Cluster zu lagern, der überfordert ist.

  • In den meisten Umgebungen ermöglicht ESXi eine erhebliche 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 in diesem Host.

  • Wenn ein ESXi-Host CPU-gesättigt wird, d.h. die virtuellen Maschinen und andere Lasten auf dem Host alle CPU-Ressourcen verlangen, die der Host hat, funktionieren latenzsensitive Workloads möglicherweise nicht gut. In diesem Fall können Sie die CPU-Last reduzieren, z. B. indem Sie einige virtuelle Maschinen ausschalten oder sie auf einen anderen Host migrieren (oder DRS die automatische Migration durchführen lassen).

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

  • Der NetScaler VPX ist eine latenzempfindliche, leistungsstarke virtuelle Appliance. Um die erwartete Leistung zu erzielen, benötigt die Appliance eine vCPU-Reservierung, Speicherreservierung und vCPU-Pinning auf dem Host. Außerdem muss Hyper-Threading auf dem Host deaktiviert werden. Wenn der Host diese Anforderungen nicht erfüllt, treten Probleme wie Hochverfügbarkeitsfailover, CPU-Anstieg innerhalb der VPX-Instanz, Trägheit beim Zugriff auf die VPX CLI, Absturz des Pitboss-Daemons, Paketausfälle und ein niedriger Durchsatz auf.

Ein Hypervisor gilt als übermäßig bereitgestellt, wenn eine der folgenden beiden 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 verbrauchen mehr vCPUs als die Gesamtzahl der pCPUs.

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

    Beispiel

    Wenn für ESX-Hypervisor der Parameter %RDY% einer VPX-vCPU in der Befehlsausgabe von esxtop größer als 0 ist, wird für den ESX-Host Zeitplanungsoverhead angegeben, was zu Latenzproblemen für die VPX-Instanz führen kann.

    Reduzieren Sie in einer solchen Situation die Mandanten auf dem Host, sodass %RDY% immer auf 0 zurückkehrt. Wenden Sie sich alternativ an den Hypervisor-Anbieter, um den Grund für die Nichteinhalten der durchgeführten Ressourcenreservierung zu prüfen.

  • 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-Plug, und das Verhalten der Instanzen kann unvorhersehbar sein, wenn Hot-Plugging versucht wird.
  • Hot-Removal ü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 versucht wird, Hot-Removal durchzuführen.

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-Auslastungsverhalten 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 verwenden, die einer anderen VM zugewiesen wurden, aber nicht verwendet werden.

    Parameter für Set ns vpxparam:

    -cpuyield: Freigabe von zugewiesenen, aber nicht genutzten CPU-Ressourcen.

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

    • NO: Reservieren Sie 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.

    • 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 Verwendung zu überschreiben.

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

    • Wenn ein Cluster gebildet wird, erhalten alle Knoten “yield=DEFAULT”.
    • Wenn ein Cluster unter Verwendung der Knoten gebildet wird, die bereits auf “yield=YES” eingestellt sind, werden die Knoten mit “yield=DEFAULT” zum Cluster hinzugefügt.

    Hinweis:

    Wenn Sie die Clusterknoten auf “yield=YES” setzen möchten, können Sie erst nach der Bildung des Clusters konfigurieren, aber nicht bevor der Cluster gebildet wurde.

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

    • YES: Erlauben Sie der VM, die Haupttaktquelle von CPU0 auf CPU1 zu verschieben.

    • NO: VM verwendet CPU0 für die Haupttaktquelle. Standardmäßig ist CPU0 die Haupttaktquelle.

  • show ns vpxparam

    Zeigt die aktuellen vpxparam-Einstellungen an.

Andere Referenzen

Support-Matrix und Nutzungsrichtlinien
August 6, 2024
Beitrag von: 
C
August 6, 2024
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.