In dem Dokumentationssatz für dieses Produkt wird die Verwendung inklusiver Sprache angestrebt. Für die Zwecke dieses Dokumentationssatzes wird Sprache als „inklusiv“ verstanden, wenn sie keine Diskriminierung aufgrund von Alter, körperlicher und/oder geistiger Behinderung, Geschlechtszugehörigkeit und -identität, ethnischer Identität, sexueller Orientierung, sozioökonomischem Status und Intersektionalität impliziert. Dennoch können in der Dokumentation stilistische Abweichungen von diesem Bemühen auftreten, wenn Text verwendet wird, der in Benutzeroberflächen der Produktsoftware fest codiert ist, auf RFP-Dokumentation basiert oder von einem genannten Drittanbieterprodukt verwendet wird. Hier erfahren Sie mehr darüber, wie Cisco inklusive Sprache verwendet.
Cisco hat dieses Dokument maschinell übersetzen und von einem menschlichen Übersetzer editieren und korrigieren lassen, um unseren Benutzern auf der ganzen Welt Support-Inhalte in ihrer eigenen Sprache zu bieten. Bitte beachten Sie, dass selbst die beste maschinelle Übersetzung nicht so genau ist wie eine von einem professionellen Übersetzer angefertigte. Cisco Systems, Inc. übernimmt keine Haftung für die Richtigkeit dieser Übersetzungen und empfiehlt, immer das englische Originaldokument (siehe bereitgestellter Link) heranzuziehen.
Dieses Dokument beschreibt die Konfiguration der maximalen Warteschlangentiefe und der ausstehenden Eingabe/Ausgabe (IO) auf einem nfnic-nativen Treiber (nfnic) für die Fibre Channel-Netzwerkkarte. Im VMware ESXi 6.7-Hypervisor wurde der Treiber für die Fibre-Channel-Netzwerkschnittstellenkarte (fnic) durch den nfnic-Treiber für alle Cisco Adapter ersetzt.
Die Standardwarteschlangentiefe des nfnic-Treibers ist auf 32 festgelegt, und bei allen ersten Releases des nfnic-Treibers gibt es keine Möglichkeit, die nfnic-Warteschlangentiefe anzupassen. Dadurch werden alle maximalen Gerätewarteschlangen- und Datenträgerplannummernanforderungen, die ausstehen, auf 32 beschränkt. Es hat auch Probleme bei der Verwendung von vSphere Virtual Volumes verursacht, da die empfohlene Warteschlangentiefe 128 beträgt. Die Auswirkungen dieses Grenzwerts sind auch bei allen VMs zu beobachten, die eine höhere Workload erleben und generell eine größere Warteschlangentiefe benötigen.
dazu beigetragen von Michael Baba, Josh Good und Alejandro Marino; Cisco TAC-Techniker.
Erweiterte Funktionen zum Hinzufügen von Funktionen zum Konfigurieren des Parameters für die Warteschlangentiefe: https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvo09082
Ab Version 4.0.0.35 des nfnic-Treibers können Sie "lun_queue_deep_per_path" über die ESXi-Befehlszeilenschnittstelle (CLI) anpassen. Diese Treiberversion kann manuell auf dem ESXi-Host installiert werden, wenn sie noch nicht vorhanden ist.
Der nfnic-Treiber 4.0.0.35 ist im UCS Blade-Firmware-Bündel 4.0.4 enthalten und kann auch separat von VMware heruntergeladen werden. Auf der Seite UCS-Hardware- und Softwarekompatibilität finden Sie die aktuellsten empfohlenen Treiber für Ihre spezielle Hardware- und Softwarekombination.
Führen Sie folgende Schritte aus, um die derzeit installierte Version des nfnic-Treibers zu überprüfen:
esxcli software vib list | grep nfnic
Sie sollten Folgendes sehen:
[root@localhost:~] esxcli software vib list | grep nfnic nfnic 4.0.0.14-1OEM.670.1.28.10302608 Cisco VMwareCertified 2019-08-24 [root@localhost:~]
Wenn Sie keine Ausgabe sehen, ist der nfnic-Treiber derzeit nicht installiert. Auf der Seite UCS-Hardware- und -Softwarekompatibilität können Sie überprüfen, ob Ihre Konfiguration den nfnic- oder fnic-Treiber verwenden soll.
Detaillierte Anweisungen zur Installation der neuesten Treiber werden in diesem Handbuch nicht behandelt. In der Dokumentation zu UCS-Treiberinstallation für gängige Betriebssysteme oder VMware finden Sie eine Schritt-für-Schritt-Anleitung zum Upgrade des Treibers. Nachdem der Treiber aktualisiert wurde, können Sie die Version mit den gleichen Befehlen wie oben überprüfen.
Nach der Installation des richtigen Treibers können wir überprüfen, ob die Modulparameter für folgende Konfigurationen verfügbar sind:
esxcli system module parameters list -m nfnic
In dieser Ausgabe sehen Sie, dass der Standardwert auf 32 festgelegt ist. Sie können jedoch einen beliebigen Wert zwischen 1 und 1024 konfigurieren. Bei Verwendung von vSphere Virtual Volumes wird empfohlen, diesen Wert auf 128 einzustellen. Wir empfehlen, sich bei weiteren Empfehlungen an VMware und Ihren Storage-Anbieter zu wenden.
Beispielausgabe:
[root@localhost:~] esxcli system module parameters list -m nfnic Name Type Value Description ------------------------ ----- ----- -------------------------------------------------------------- lun_queue_depth_per_path ulong nfnic lun queue depth per path: Default = 32. Range [1 - 1024] [root@localhost:~]
Um den Parameter "Queue Depth" (Tiefe der Warteschlange) zu ändern, wird der folgende Befehl ausgeführt. Im folgenden Beispiel ändern wir es in 128, aber Ihr Wert kann je nach Umgebung unterschiedlich sein.
esxcli system module parameters set -m nfnic -p lun_queue_depth_per_path=128
Mit dem gleichen Befehl wie oben können wir die Änderung konfigurieren:
[root@localhost:~] esxcli system module parameters list -m nfnic Name Type Value Description ------------------------ ----- ----- -------------------------------------------------------------- lun_queue_depth_per_path ulong 128 nfnic lun queue depth per path: Default = 32. Range [1 - 1024] [root@localhost:~]
Jetzt können wir die ausstehenden E/As auf dem Protokollendpunkt so konfigurieren, dass sie der Warteschlangentiefe oben entsprechen (in unserem Beispiel 128), und dann überprüfen, ob beide Werte in 128 geändert wurden.
HINWEIS: Möglicherweise müssen Sie den Host neu starten, bevor diese Konfigurationsänderung vorgenommen werden kann.
So ändern Sie die Warteschlangentiefe für ein bestimmtes Gerät:
esxcli storage core device set -O 128 -d naa.xxxxxxxxx
Mit dem folgenden Befehl können Sie die Geräte-ID ermitteln:
esxcli storage core device list
So bestätigen Sie die Änderungen für ein bestimmtes Gerät:
esxcli storage core device list -d naa.xxxxxxxxxx
Ein Beispiel mit Ausgabe. Wie wir sehen, sind die Werte "Device Max Queue Depth:" und "No of ausstehend IOs with Competitive Worlds:" immer noch 32.
[root@localhost:~] esxcli storage core device list -d naa.600a09803830462d803f4c6e68664e2d naa.600a09803830462d803f4c6e68664e2d Display Name: VMWare_SAS_STG_01 Has Settable Display Name: true Size: 2097152 Device Type: Direct-Access Multipath Plugin: NMP Devfs Path: /vmfs/devices/disks/naa.600a09803830462d803f4c6e68664e2d Vendor: NETAPP ...snip for length... Is Boot Device: false Device Max Queue Depth: 32 No of outstanding IOs with competing worlds: 32 Drive Type: unknown RAID Level: unknown Number of Physical Drives: unknown Protection Enabled: false PI Activated: false PI Type: 0 PI Protection Mask: NO PROTECTION Supported Guard Types: NO GUARD SUPPORT DIX Enabled: false DIX Guard Type: NO GUARD SUPPORT Emulated DIX/DIF Enabled: false
Für dieses Gerät wird jetzt auf 128 geändert.
esxcli storage core device set -O 128 -d naa.600a09803830462d803f4c6e68664e2d
Bei der Überprüfung derselben Ausgabe sehen wir nun "Device Max Queue Depth:" (Max-Warteschlangentiefe:) und "No of ausstehender IOs with Competitive Worlds:" (Anzahl der ausstehenden E/A-s mit konkurrierenden Welten:) jeweils 128. Wenn die Änderungen nicht sofort übernommen werden, ist möglicherweise ein Neustart des ESXi-Hosts erforderlich.
[root@localhost:~] esxcli storage core device list -d naa.600a09803830462d803f4c6e68664e2d naa.600a09803830462d803f4c6e68664e2d Display Name: VMWare_SAS_STG_01 Has Settable Display Name: true Size: 2097152 Device Type: Direct-Access Multipath Plugin: NMP Devfs Path: /vmfs/devices/disks/naa.600a09803830462d803f4c6e68664e2d Vendor: NETAPP ...snip for length... Is Boot Device: false Device Max Queue Depth: 128 No of outstanding IOs with competing worlds: 128 Drive Type: unknown RAID Level: unknown Number of Physical Drives: unknown Protection Enabled: false PI Activated: false PI Type: 0 PI Protection Mask: NO PROTECTION Supported Guard Types: NO GUARD SUPPORT DIX Enabled: false DIX Guard Type: NO GUARD SUPPORT Emulated DIX/DIF Enabled: false