Setup-Guide NVMe-oF unter Proxmox VE

Discovery

NVMe-oF TCP Targets können nun wie folgt erkannt werden:

nvme discover --transport=tcp --traddr=<IP-STORAGE>

Je nach Implementation des NVMe-oF Protokolls auf dem SAN, werden hier alle verfügbaren Controller / IPs des SANs zurückgegeben. In manchen Fällen erhält man allerdings nur ein Log Entry von der IP, auf welchem der Request gestellt worden ist. Meist sind aber noch weitere IPs (bspw. bei hochverfügbaren Multicontroller Systemen) zum Verbinden verfügbar.

Eine Ausgabe mit allen Endpunkten sieht bspw. wie folgt aus:

root@pve-01:~# nvme discover --transport=tcp --traddr=192.168.50.10 --trsvcid=4420

Discovery Log Number of Records 2, Generation counter 7
=====Discovery Log Entry 0======
trtype:  tcp
adrfam:  ipv4
subtype: nvme subsystem
treq:    not specified, sq flow control disable supported
portid:  1
trsvcid: 4420
subnqn:  [FAKE]
traddr:  192.168.50.10
eflags:  none
sectype: none
=====Discovery Log Entry 1======
trtype:  tcp
adrfam:  ipv4
subtype: nvme subsystem
treq:    not specified, sq flow control disable supported
portid:  2
trsvcid: 4420
subnqn:  [FAKE]
traddr:  192.168.51.10
eflags:  none
sectype: none
=====Discovery Log Entry 2======
trtype:  tcp
adrfam:  ipv4
subtype: nvme subsystem
treq:    not specified, sq flow control disable supported
portid:  2
trsvcid: 4420
subnqn:  [FAKE]
traddr:  192.168.50.11
eflags:  none
sectype: none
=====Discovery Log Entry 3======
trtype:  tcp
adrfam:  ipv4
subtype: nvme subsystem
treq:    not specified, sq flow control disable supported
portid:  2
trsvcid: 4420
subnqn:  [FAKE]
traddr:  192.168.51.11
eflags:  none
sectype: none

Targets kontrollieren

Die Targets / Pfade können mit nvme list-subsys -v, samt IO-Policy aufgelistet werden.

Allerdings werden die ANA-States (Vergleichbar mit ALUA) nicht angezeigt.

Diese können mit nvme list-subsys -o json /dev/nvme0n1 eingesehen werden (optimized / non-optimized bspw.).

Automatisches Setup bei Start

Targets verbinden

Mit nvme connect bzw. nvme connect-all aufgebaute Verbindungen überleben keinen Neustart. Für den automatischen Verbindungsaufbau beim Booten werden die Discovery-Parameter in der Datei /etc/nvme/discovery.conf hinterlegt, ein Eintrag pro Discovery-Portal:

--transport=tcp --traddr=192.168.50.10 --trsvcid=4420 [--ctrl-loss-tmo=-1 --keep-alive-tmo=10] 
--transport=tcp --traddr=192.168.51.10 --trsvcid=4420 [--ctrl-loss-tmo=-1 --keep-alive-tmo=10] 
--transport=tcp --traddr=192.168.50.11 --trsvcid=4420 [--ctrl-loss-tmo=-1 --keep-alive-tmo=10] 
--transport=tcp --traddr=192.168.51.11 --trsvcid=4420 [--ctrl-loss-tmo=-1 --keep-alive-tmo=10]

Bitte ggf. Konfiguration in [] mit Optimierte Multipathing Einstellungen abgleichen.

Beim Systemstart führt der systemd-Service nvmf-autoconnect.service effektiv ein nvme connect-all gegen alle dort hinterlegten Einträge aus und stellt damit sämtliche Pfade automatisch wieder her.

Der Service muss aktiviert sein:

systemctl enable nvmf-autoconnect.service

Prüfen lässt sich der Status mit:

systemctl is-enabled nvmf-autoconnect.service

I/O Policy umstellen

Standardmäßig befinden sich die NVMe-oF Targets in der io-policy numa, um dies bei Start automatisch zu bspw. Round-Robin zu ändern, bedarf es einer udev-Regel.

Folgende I/O Policies sind verfügbar:

Zur Laufzeit (nicht reboot-fest):

echo "round-robin" > /sys/class/nvme-subsystem/nvme-subsys0/iopolicy #subsys0 entsprechend anpassen

Damit die Policy beim Start automatisch gesetzt wird, ist die udev-Regel /etc/udev/rules.d/71-nvme-io-policy.rules erforderlich:

ACTION=="add|change", SUBSYSTEM=="nvme-subsystem", ATTR{iopolicy}="round-robin"

Aktivieren und prüfen zur Laufzeit:

udevadm control --reload-rules
udevadm trigger --subsystem-match=nvme-subsystem
cat /sys/class/nvme-subsystem/nvme-subsys*/iopolicy

Fehlende Targets nach Boot

Persistente Konfiguration fehlt

Bitte Automatisches Setup bei Start (siehe oben) berücksichtigen

Netzwerkverbindung zu spät verfügbar

Der nvmf-autoconnect.service startet zwar erst nach network-online.target, dieses Target gilt jedoch bereits als erreicht, sobald ifupdown2 die Interfaces konfiguriert hat und nicht, wenn das Netzwerk tatsächlich Pakete transportiert.

LACP-Negotiation am Bond oder STP-Listening/Learning am Switch-Port (ohne Edge-Port-/PortFast-Konfiguration bis zu 30 Sekunden) können zu diesem Zeitpunkt noch andauern. Der einmalig ausgeführte nvme connect-all läuft dann in dieses Zeitfenster: TCP-Connects zu noch nicht erreichbaren Portalen schlagen fehl und werden nicht wiederholt.

Typisches Symptom: Nach dem Boot fehlen einzelne Pfade, ein manueller Connect funktioniert anschließend jedoch problemlos. --ctrl-loss-tmo=-1 hilft hier nicht, da der Parameter nur bestehende Verbindungen schützt und ein nie zustande gekommener Controller kann nicht reconnecten.

Diagnose

Zeitlichen Zusammenhang zwischen Netzwerk-Start und Connect-Fehlern prüfen:

journalctl -b -u networking.service -u nvmf-autoconnect.service -o short-precise

Liegen die connect failed-Meldungen nur Millisekunden bis wenige Sekunden hinter dem Abschluss von networking.service, ist die Race-Condition bestätigt.

Mögliche Lösung (statisch): Startverzögerung per systemd-Override

Statt die Unit-Datei direkt zu bearbeiten (würde bei Paket-Updates überschrieben), wird ein Drop-in angelegt:

systemctl edit nvmf-autoconnect.service

Inhalt:

[Service]
ExecStartPre=/bin/sleep 15

Der Service wartet damit 15 Sekunden, bevor nvme connect-all ausgeführt wird und ausreichend für LACP-Verbindungen; bei STP ohne Edge-Port ggf. auf 30–45 Sekunden erhöhen. (Nachhaltiger lässt sich die Ursache switchseitig beheben, indem die Host-Ports als RSTP-Edge-Ports (PortFast) konfiguriert werden, damit entfällt das Forwarding-Delay-Fenster vollständig.) Das Drop-in liegt anschließend unter /etc/systemd/system/nvmf-autoconnect.service.d/override.conf.

Verifikation

Override prüfen und Reboot-Test durchführen:

systemd-delta --type=extended | grep nvmf
systemctl cat nvmf-autoconnect.service

Nach dem Neustart müssen alle Pfade vorhanden sein:

nvme list-subsys

Zusätzlich im Journal kontrollieren, dass der Service erst nach der Wartezeit ausgeführt wurde und keine Connect-Fehler mehr auftreten:

journalctl -b -u nvmf-autoconnect.service