Supportmatrix und Nutzungsrichtlinien

Dieses Dokument listet die verschiedenen Hypervisoren und Funktionen auf, die auf NetScaler VPX- und VPX FIPS-Instanzen unterstützt werden, es sei denn, ein bestimmter Hypervisor wird ausdrücklich als auf VPX FIPS nicht unterstützt angegeben. Das Dokument beschreibt auch deren Nutzungsrichtlinien und bekannte Einschränkungen.

VPX-Instanz auf XenServer

VPX-Instanz auf VMware ESXi-Hypervisor

Hinweis:

Die Unterstützung für jeden ESXi-Patch 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

VPX-Instanz auf Azure Local

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 Support-Vorfall direkt beim Drittanbieter-Partner (Nutanix).

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

VPX-Instanz auf generischem KVM

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 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 hängen Sie "kvm_intel.preemption_timer=0" an die Variable GRUB_CMDLINE_LINUX an.

  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 hängen Sie "kvm_intel.preemption_timer=0" an die Variable GRUB_CMDLINE_LINUX an.
  2. Generieren Sie grub.cfg mithilfe des Befehls "# grub-mkconfig -o /boot/grub/grub.cfg “ neu.
  3. Starten Sie die Hostmaschine neu.

VPX-Instanz in öffentlichen Clouds

Auf Hypervisoren unterstützte VPX-Funktionen

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

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 aufgeführt sind:

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

  • Kurzes Timeout: 3 Sekunden
  • Langes Timeout: 90 Sekunden
• Bei LACP sollten 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 erfolgt bei Hochverfügbarkeit nicht, 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 statischem LA wird jeglicher vom Peer initiierter Datenverkehr auf der Instanz verworfen.
  • Damit die VLAN-Tagging-Funktion auf VMware ESX funktioniert, stellen Sie die VLAN-ID der Portgruppe auf 1–4095 auf dem vSwitch des VMware ESX-Servers ein.
• 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 ein 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™

Unterstützte NICs für NetScaler VPX

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

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 überbelegten Host oder Cluster laufen.

• 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 ist, 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 nutzen zu können. 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 eine vCPU-Reservierung, eine Speicherreservierung und ein 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 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 zu den Problemen, die im ersten Punkt unter Nutzungsrichtlinien erwähnt werden. 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:

  Für den ESX-Hypervisor, wenn der %RDY%-Parameter einer VPX-vCPU in der esxtop-Befehlsausgabe größer als 0 ist, wird angenommen, dass der ESX-Host Scheduling-Overheads aufweist, die zu latenzbezogenen Problemen für die VPX-Instanz führen können.

  Reduzieren Sie in einer solchen Situation die Belegung auf dem Host, sodass %RDY% immer 0 zurückgibt. Alternativ wenden Sie sich an den Hypervisor-Anbieter, um den Grund für die Nichtbeachtung 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 kein Hot-Plug, und das Verhalten der Instanzen kann unvorhersehbar sein, wenn Hot-Plugging versucht wird.
• Das Hot-Entfernen über die AWS-Webkonsole oder die AWS-CLI-Schnittstelle wird für die PV-, SRIOV- und ENA-Schnittstellen für NetScaler nicht unterstützt. Das Verhalten der Instanzen kann unvorhersehbar sein, wenn ein Hot-Entfernen 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 die Nutzung von CPU-Ressourcen, 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: 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-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 Auslastung zu überschreiben.

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

  • Wenn ein Cluster gebildet wird, starten alle Knoten mit „yield=DEFAULT“.
  • Wenn ein Cluster mit Knoten gebildet wird, die bereits auf „yield=YES“ eingestellt 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 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.

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

• show ns vpxparam

  Zeigen Sie die aktuellen vpxparam-Einstellungen an.

Weitere Referenzen

• Für Citrix Ready-Produkte besuchen Sie den Citrix Ready Marketplace.

• Für Support zu Citrix Ready-Produkten siehe die Citrix Ready Partnerseite.

• Für VMware ESX Hardwareversionen siehe Upgrading VMware Tools.