ISCSI Probleme mit Routing zu SAN Dell ME5024

B

BlackBird669

New Member
Feb 17, 2025
6
0
1
Hallo zusammen,

wir wollen von ESXi auf Proxmox wechseln und sind gerade am ausloten mit der vorhergehenden Serverhardware(2x Dell Poweredge R630)

Da auf der ME5 genügend Anschlüße vorhanden sind haben wir die 2 alten Server auch direkt an die SAN gehängt.
Verkabelung redundant pro Server je ein Kabel auf Controller A und B. wie lt. Doku von Dell.
Verbunden mit 25 Gb/s lt. ME5 und ethtool auf Proxmox

An der Proxmox-Installation habe ich noch nichts gemacht, keine Konfigs geändert oder dergleichen.
Habe nur die IP Adressen bei den NICs eingetragen die die Gegenstücke zur ME5 bieten.

Auszug aus Interfaces

Code: 
auto enp129s0f0np0
iface enp129s0f0np0 inet static
        address 10.10.30.110/24
        mtu 9000
#iSCSI A

auto enp129s0f1np1
iface enp129s0f1np1 inet static
        address 10.10.31.110/24
        mtu 9000
#iSCSI B


Wenn ich nun das Target verbinden will scheint es sofort im Auswahlfenster auf. Aber sobald ich es anwähle und auf okey gehe läuft das Rad und er geht in einen Connection Error.
Auf der ME5 schlägt der Proxmox mit seiner Initator ID auf aber selbst wenn ich die Verbindung nochmal aufbauen will kommt nur Connection Error.

Proxmox legt zwar die Verbindung an, ich bekomme aber nur in 1 von 10 Fällen vielleicht eine LUN präsentiert.
Meist einfach nur Connection Error.

Ping geht ohne Probleme.
traceroute schlägt fehl und traceroute auf tcp bringt hohe Latenz.

Code: 
root@PROX01:~# traceroute -T -p 3260 10.10.30.100
traceroute to 10.10.30.100 (10.10.30.100), 30 hops max, 60 byte packets
 1  10.10.30.100 (10.10.30.100)  5.606 ms  5.859 ms *
root@PROX01:~# traceroute -T -p 3260 10.10.30.100
traceroute to 10.10.30.100 (10.10.30.100), 30 hops max, 60 byte packets
 1  10.10.30.100 (10.10.30.100)  5.168 ms  5.488 ms *
root@PROX01:~# ping 10.10.30.100
PING 10.10.30.100 (10.10.30.100) 56(84) bytes of data.
64 bytes from 10.10.30.100: icmp_seq=1 ttl=64 time=0.147 ms
64 bytes from 10.10.30.100: icmp_seq=2 ttl=64 time=0.055 ms
64 bytes from 10.10.30.100: icmp_seq=3 ttl=64 time=0.071 ms
64 bytes from 10.10.30.100: icmp_seq=4 ttl=64 time=0.051 ms
64 bytes from 10.10.30.100: icmp_seq=5 ttl=64 time=0.087 ms


Das Problem besteht auf beiden Servern!
Einmal ist eine Broadcom BCM57414 10/25 GB verbaut
Code: 
root@PROX02:~# ethtool -i enp129s0f0np0
driver: bnxt_en
version: 6.8.12-4-pve
firmware-version: 220.0.59.0/pkg 22.00.08.30
expansion-rom-version:
bus-info: 0000:81:00.0
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
supports-priv-flags: no

und beim 2ten Server ein Intel XX710-DA2

fw info folgt.

Die in Produktiven Betrieb befindlichen Server mit BCM57414 Karte und ESXi haben weder bei Traceroute noch bei Ping Probleme.

Leider finde ich nirgends was passendes im Web... ich hoffe hier kann man mir helfen!

Edit: Auszug Interfaces richtig gestellt.
 
Last edited:
Hallo,
Ihrer Beschreibung zufolge haben Sie zwei Pfade zum Speicher. Damit das System Anfragen richtig verarbeiten kann, müssen Sie im Allgemeinen Multipath aktivieren.
Außerdem haben Sie gesagt, dass Sie Gegenstück-IPs auf PVE aktivieren, aber Sie führen Tracerouting durch und pingen das Subnetz 10.10, obwohl Ihre IPs 192.168 sind.

Da Sie sagten, dass Sie das SAN direkt verbunden haben, sollten die IPs im selben Subnetz sein.

Viele Grüße


Blockbridge : Ultra low latency all-NVME shared storage for Proxmox - https://www.blockbridge.com/proxmox
 
  • Like
Reactions: Johannes S
Hallo bbgeek17,

vielen Dank für die Antwort!
Sie haben recht, ich habe von den beiden Servern die eingestellten IPs beim posten vertauscht... ist nun im Original Post korrigiert.

Habe den Fehler vorher gefunden... ich verlasse mich nie wieder auf eine alte IDRAC. Ich habe natürlich die Firmwareupdates über diese durchgeführt nur leider wurden nicht die aktuellsten FW Versionen installiert.
Somit hatte ich eine veraltete FW. Habe nu auf Version 231.0.153.0 aktualisiert und siehe da es funktioniert ohne Probleme...

Vermute das selbe Problem bei der Intel Karte... kann das aber erst morgen prüfen.

Ich habe einfach angenommen das es bereits die aktuellste FW ist und nicht nachgeprüft da mir ja die IDrac keine neuere FW angeboten hat.

Man lernt nie aus.
Danke!
 
Ich hoffe du hast das Multipathing sauber konfiguriert. Wenn du iSCSI mit Multipath nutzt, darfst du die iSCSI Ziele nicht per GUI einrichten, sondern erst das multipath auf der CLI und dann das LVM-VG generieren, womit du in der GUI deinen Datastore erzeugst.
 
Puh okey, das war mir nicht klar, was wäre jetzt der bester Weg das zu korrigieren? ich dachte mir das einfache in hinzufügen in den Multipath reicht.
Soll ich die Proxmox instanz neu aufsetzen oder genügt es wenn ich das LVM wieder entferne und neu einbinde?

Desweiteren bin ich neu in der ganzen Proxmox-umgebung und habe mir das Multipath aus dem Forum zusammenkopiert... :/

Code: 
##Default System Values
defaults {
user_friendly_names yes
find_multipaths yes
polling_interval 2
queue_without_daemon no
path_selector "round-robin 0"
path_grouping_policy multibus
uid_attribute ID_SERIAL
rr_min_io 100
failback immediate
no_path_retry queue
}

## Blacklist Exceptions
blacklist_exceptions {
device {
vendor "DellEMC"
product "ME5"
}

}
## Dell Device Configuration
devices {
device {
vendor "DellEMC"
product "ME5"
path_grouping_policy group_by_prio
path_checker "tur"
hardware_handler "1 alua"
prio "alua"
failback immediate
rr_weight "uniform"
path_selector "round-robin 0"
}
}

Vermute das ich mir die Device Configuration eigentlich sparen kann da ich ja sowieso nur die eine SAN habe oder?
die Multipath -l1 Ausgabe dazu:

Code: 
mpatha (3600c0ff00065ad314b22b36701000000) dm-0 DellEMC,ME5
size=279G features='1 queue_if_no_path' hwhandler='1 alua' wp=rw
|-+- policy='round-robin 0' prio=0 status=active
| `- 10:0:0:2 sdb 8:16 active undef running
`-+- policy='round-robin 0' prio=0 status=enabled
  `- 11:0:0:2 sdd 8:48 active undef running
mpathb (3600c0ff00065ad310c70b86701000000) dm-1 DellEMC,ME5
size=93G features='1 queue_if_no_path' hwhandler='1 alua' wp=rw
|-+- policy='round-robin 0' prio=0 status=active
| `- 10:0:0:3 sdc 8:32 active undef running
`-+- policy='round-robin 0' prio=0 status=enabled
  `- 11:0:0:3 sde 8:64 active undef running

Weiters, soll zuerst der Cluster konfiguriert sein bevor man Multipath einrichtet oder ist das egal?
Vielen, vielen Dank für eueren Input!
 
Last edited:
Hi, ich empfehle immer die multipath Konfiguration zu nutzen, welche der Hersteller vorschlägt. Da sind in der Regel schon einige Dinge optimiert und gerade was das Failover angeht, sind da oft Einstellungen, welche für einen korrekten Betrieb verpflichtend sind.

Da du ja mpatha und mpathb siehst, ist das ja schon alles ganz gut. In der GUI kannst du beim LVM erzeugen leider keine mpath Geräte auswählen, daher einfach:
pvcreate /dev/mapper/mpatha
und dann
vgcreate LUN001 /dev/mapper/mpatha (für LUN001 einfach deinen gewünschten Namen nehmen)

Dann kannst du beim LVM erzeugen in der GUI deine "LUN001" auswählen.
 
Okey, vielen Dank für deinen Input, werde mir das ganze die nächsten Tage näher ansehen und testen.
Danke!
 
Hallo Zusammen

Wir haben bei uns ein System mit drei Nodes welche im Cluster laufen.
Zur Verfügung stehen zwei iscsi Targets (Synology) welche auf allen drei Hosts eingerichtet sind.
Beide Targets sind über die identischen IP Adressen von allen Hosts erreichbar.

Nur bei einem Host wird eines der beiden Targets nicht erkannt, beziehungswiese hat ein Fragezeichen.
Multipath ist installiert und sieht auch bei allen drei Hosts identisch aus, auch sind beide wwid von der Blacklist ausgenommen.
Pingen ab dem Host auf den Synology Nas geht ohne probleme.

Jetzt stehe ich etwas auf dem Schlauch wieso das diese eine Target auf dem einen Host nicht angezeigt wird.
Reboot haben wir natürlich schon gemacht aber hat keinen Einfluss, geht auch danach nicht.

An der Installation wurde ausser Software Updates nichts verändert, Synology läuft seit Jahren auf einer 6.2 Version.
Einzig wurde vor kurzem das Update auf Proxmox 8.4.1 gemacht, dies aber auf allen Nodes.

Vielleicht hat da noch jemand eine zündende Idee. :cool:

1745500294929.png
 
Irgendwie sieht das etwas komisch aus, aber vermutlich liegt das nur an der Benamung der Datastores.
Zu deinem Fehler:
Check mal auf dem NAS ob auch bei beiden Targets die gleichen iqn berechtigt sind. Das ist die einzige Fehlerquelle, welche genau so ein Phänomen zeigt.
 
  • Like
Reactions: Johannes S
Hi Falk

Vielen Dank für deine Rückmeldung.
Ich wüsste gerade nicht wo man dies nachschauen kann, CHAP ist nicht aktiviert demzufolge kann jeder im Netzwerk auf den Storage zugreifen.
Synology ist noch auf 6.2.3, mehrere Verbindungen sind auch zugelassen. Es wurde am NAS seit sicher 2 Jahren nichts mehr verändert.
Von Node 1 und 2 sind alle IP Adressen ersichtlich auf dem NAS bei beiden Targets.
Ich vermute mehr das auf Seiten Proxmox etwas bei einem Update nicht korrekt übernommen wurde.
 
Hallo @blunt. Die CHAP-Authentifizierung basiert auf der Zonenkonfiguration. Wenn Sie mit SAN vertraut sind, müssen Sie eine ähnliche Beziehung zwischen iSCSI-Ziel (SAN) und iSCSI-Initiator (PVE-Host) herstellen. Im Wesentlichen müssen Sie dem Initiator den Zugriff auf das Ziel erlauben. Diese Konfiguration erfolgt SAN-seitig. Sie können CHAP hinzufügen, wenn Sie möchten.

Blockbridge : Ultra low latency all-NVME shared storage for Proxmox - https://www.blockbridge.com/proxmox
 
Tompa said:
Hi Falk

Vielen Dank für deine Rückmeldung.
Ich wüsste gerade nicht wo man dies nachschauen kann, CHAP ist nicht aktiviert demzufolge kann jeder im Netzwerk auf den Storage zugreifen.
Synology ist noch auf 6.2.3, mehrere Verbindungen sind auch zugelassen. Es wurde am NAS seit sicher 2 Jahren nichts mehr verändert.
Von Node 1 und 2 sind alle IP Adressen ersichtlich auf dem NAS bei beiden Targets.
Ich vermute mehr das auf Seiten Proxmox etwas bei einem Update nicht korrekt übernommen wurde.
Click to expand...
Auch wenn nix aktiv geändert wurde, sollte man das trotzdem überprüfen.
Mein normales Troubleshooting Vorgehen lautet, auch alles wo man sich sicher ist und wo nix geändert wurde überprüfen.
Es gibt nur 2 Möglichkeiten, entweder passt irgendwas an der iqn nicht, es ist sehr unwahrscheinlich aber auch die kann man ändern oder es passt etwas IP seitig nicht, wie z.B. Jumbo Frames.
 
Wenn der Speicher Kronos vom selben Gerät kommt, kann es eigentlich nur am Mapping (iqn) liegen.
 
Ok ich habe die iqn geprüft, da hat sich nichts geändert.
Zum einen sehe ich die IQN von Synology und zum anderen die IQN von Proxmox welche mir in Synology angezeigt werden. Heisst alle diejenigen welche auch verbunden sind.
Auf dem LUN von Kronos sind alle IQN's aller Nodes vorhanden, nur eben auf der LUN von Artemis sind nur zwei der drei IQN's sichtbar.
Allenfalls ist in der Proxmox config irgendwas nicht mehr korrekt so dass dieses LUN nicht verbunden wird.

1745830851459.png
 
Also ich sehe die iqn des 3. Node bei Artemis nicht. Da fehlt wohl was. ;)
 
Genau und da liegt der Hund begraben....;)
Ich vermute daher stark das es an der Proxmox Config liegen muss, bei Kronos geht ja alles und es ist der gleiche Datastore. (hat ja nur eine Syno)
Manuell hinzufügen kann man ja nichts, der Node erscheint erst dann wenn die Verbindung geklappt hat.
 
Man muss die iqn des Initiators (hier PVE) immer auf dem Storage eintragen und erlauben, dass diese iqn auf diese LUN zugreifen kann.
So funktioniert iSCSI und hat rein gar nix mit Proxmox zu tun.
 
  • Like
Reactions: Johannes S
Ich frage mich, ob @blunt die Liste der aktiven Sitzungen und nicht die Liste der zulässigen IQNs betrachtet. Offensichtlich sind die IQNs nicht in der aktiven Sitzung, wenn sie keine Verbindung herstellen dürfen.
Nichts für ungut, aber @blunt, du hast den Thread eines anderen gekapert und außer einem Screenshot weder Fehlerprotokolle noch Konfigurationsparameter bereitgestellt.
Ich würde dringend empfehlen, einen eigenen Thread zu eröffnen und genau diese Liste einzugeben:
pvesm status
iscsiadm -m node
iscsiadm -m session
lsscsi
cat /etc/pve/storage.cfg
journalctl -n 100 (vorausgesetzt, dein iSCSI-Daemon versucht es erneut)

Viele Grüße


Blockbridge : Ultra low latency all-NVME shared storage for Proxmox - https://www.blockbridge.com/proxmox
 
  • Like
Reactions: Johannes S and Falk R.
Ja das ist so, der eine iscsi ist nicht aktiv wie auch das zugehörige LVM.
kann man dies wieder aktivieren?
1745853251366.png

Sorry habe in der Suche nichts besseres gefunden und seit Februar war da nichts mehr los daher habe ich das mal in diesen Thread gepostet.
 
Tompa said:
Ja das ist so, der eine iscsi ist nicht aktiv wie auch das zugehörige LVM.
kann man dies wieder aktivieren?
Click to expand...
Falls du einen Login getestet hast und das immer noch so bleibt, indem du die iqn einträgst oder berechtigst auf dem Target.
Tompa said:
View attachment 85525

Sorry habe in der Suche nichts besseres gefunden und seit Februar war da nichts mehr los daher habe ich das mal in diesen Thread gepostet.
Click to expand...
 
You must log in or register to reply here.
Top Bottom