iSCSI: Unnütze Einträge bzgl. "no route to host" im daemon.log

[larsen]

Hallo,

wir nutzen ein SAN im Zusammenspiel mit Proxmox, welches direkt (ohne Switch) über zwei Kabel am Server angeschlossen ist. Alles funktioniert soweit, aber mir sind störende Einträge im Log aufgefallen, die ich gerne unterbinden würde.

Der Server hat zwei Interfaces für iSCSI. Je eines ist mit je einem Port des SAN verbunden:

• enp2s0f0, 10.0.3.240 --> 10.0.3.140 (SAN)
• enp2s0f1, 10.1.3.250 --> 10.1.3.150 (SAN)

Alle 7 Sekunden gibt es folgende Einträge im daemon.log:

Feb  1 16:35:41 atl-vm04 iscsid: connect to 10.1.4.170:3260 failed (No route to host)
Feb  1 16:35:41 atl-vm04 iscsid: connect to 10.1.4.170:3260 failed (No route to host)
Feb  1 16:35:41 atl-vm04 iscsid: connect to 10.0.3.140:3260 failed (No route to host)
Feb  1 16:35:41 atl-vm04 iscsid: connect to 10.0.1.100:3260 failed (No route to host)
Feb  1 16:35:41 atl-vm04 iscsid: connect to 10.0.1.100:3260 failed (No route to host)
Feb  1 16:35:41 atl-vm04 iscsid: connect to 10.1.1.110:3260 failed (No route to host)
Feb  1 16:35:41 atl-vm04 iscsid: connect to 10.1.1.110:3260 failed (No route to host)
Feb  1 16:35:41 atl-vm04 iscsid: connect to 10.1.2.130:3260 failed (No route to host)
Feb  1 16:35:41 atl-vm04 iscsid: connect to 10.1.2.130:3260 failed (No route to host)
Feb  1 16:35:41 atl-vm04 iscsid: connect to 10.1.3.150:3260 failed (No route to host)
Feb  1 16:35:41 atl-vm04 iscsid: connect to 10.0.2.120:3260 failed (No route to host)
Feb  1 16:35:41 atl-vm04 iscsid: connect to 10.0.2.120:3260 failed (No route to host)
Feb  1 16:35:41 atl-vm04 iscsid: connect to 10.0.4.160:3260 failed (No route to host)
Feb  1 16:35:41 atl-vm04 iscsid: connect to 10.0.4.160:3260 failed (No route to host)

iscsid versucht anscheinend, sich über jedes Interface mit jedem per Discovery entdeckten Portal(?) zu verbinden, was aber nur bei den zwei vorhandenen Verbindungen funktionieren kann. Die Startart ist nur für die zwei Verbindungen auf automatisch gesetzt:

atl-vm04:# grep -R startup /etc/iscsi/nodes/iqn.1986-03.com.hp:storage.msa2040.15472745cf | grep autom
./10.0.3.140,3260,5/iscsi_enp2s0f0:node.startup = automatic
./10.1.3.150,3260,6/iscsi_enp2s0f1:node.startup = automatic

Alle 3 Minuten und 38 Sekunden kommt solch ein Eintrag:

Feb  1 16:07:46 atl-vm04 pvestatd[1524]: command '/usr/bin/iscsiadm --mode node --targetname iqn.1986-03.com.hp:storage.msa2040.15472745cf --login' failed: exit code 15

Vermutlich möchte sich iscsid mit jedem verfügbaren Portal verbinden, was aber natürlich ohne entsprechende Verbindung nicht funktionieren kann (und auch gar nicht benötigt wird).
Wie kann ich dieses Verhalten deaktivieren?

Ich hatte an Löschen der Einträge in "/etc/iscsi/nodes/iqn.1986-03.com.hp:storage.msa2040.15472745cf" gedacht, aber habe bei meiner Recherche gelesen, dass diese ggf. automatisch wiederhergestellt werden.
Komplett per rsyslog ausfiltern möchte ich die Einträge nicht, weil sie ggf. ja für die existierende Verbindung auftreten könnten, wenn wirklich mal ein Problem besteht.

 

[mweigelt]

Hi,

ist dasselbe Problem wie hier: https://forum.proxmox.com/threads/multipath-iscsi-problems-with-8-1.137953/
und https://forum.proxmox.com/threads/multipath-iscsi-problems-with-8-1.137953/#post-623958

Gibt ein Ticket: https://bugzilla.proxmox.com/show_bug.cgi?id=5173

 

[larsen]

Besten Dank!

 

[Falk R.]

Ich sehe das jetzt gerade erst, da ist das Portbinding aktiviert. Bei vSphere ist das altbekannt und dort durch falsche Einrichtung des iSCSI Adapters geschehen. In der multipath.conf müsste man das anpassen können. Dieses Verhalten wurde bei einer DELL Equalogic immer zwingend benötigt.
Bei klassischem 2 Fabric Setup aber unerwünscht. Ich werde auch mal im Internet suchen wie die Option zu konfigurieren geht.

 

[Falk R.]

Mein vorheriger Post kann vergessen werden, Linux macht so komische Sachen wie die ESXi Server nicht.

Der Server hat zwei Interfaces für iSCSI. Je eines ist mit je einem Port des SAN verbunden:

• enp2s0f0, 10.0.3.240 --> 10.0.3.140 (SAN)
• enp2s0f1, 10.1.3.250 --> 10.1.3.150 (SAN)

Das sieht gut aus.

iscsid versucht anscheinend, sich über jedes Interface mit jedem per Discovery entdeckten Portal(?) zu verbinden, was aber nur bei den zwei vorhandenen Verbindungen funktionieren kann. Die Startart ist nur für die zwei Verbindungen auf automatisch gesetzt:

Wie machst du das Discovery und was spuckt er denn da aus?

atl-vm04:# grep -R startup /etc/iscsi/nodes/iqn.1986-03.com.hp:storage.msa2040.15472745cf | grep autom
./10.0.3.140,3260,5/iscsi_enp2s0f0:node.startup = automatic
./10.1.3.150,3260,6/iscsi_enp2s0f1:node.startup = automatic

Alle 3 Minuten und 38 Sekunden kommt solch ein Eintrag:

Feb  1 16:07:46 atl-vm04 pvestatd[1524]: command '/usr/bin/iscsiadm --mode node --targetname iqn.1986-03.com.hp:storage.msa2040.15472745cf --login' failed: exit code 15

Vermutlich möchte sich iscsid mit jedem verfügbaren Portal verbinden, was aber natürlich ohne entsprechende Verbindung nicht funktionieren kann (und auch gar nicht benötigt wird).
Wie kann ich dieses Verhalten deaktivieren?

Ich hatte an Löschen der Einträge in "/etc/iscsi/nodes/iqn.1986-03.com.hp:storage.msa2040.15472745cf" gedacht, aber habe bei meiner Recherche gelesen, dass diese ggf. automatisch wiederhergestellt werden.

Nur bei einem erneuten Discovery. Also eigentlich nur manuell oder beim Reboot.

Eigentlich müsste das auch ganz gut Performance kosten, da er ständig nach Pfaden sucht.

 

[fweber]

Vermutlich möchte sich iscsid mit jedem verfügbaren Portal verbinden, was aber natürlich ohne entsprechende Verbindung nicht funktionieren kann (und auch gar nicht benötigt wird).

Um das zu prüfen, könntest du bitte die Ausgabe der folgenden beiden Kommandos posten?

iscsiadm -m node
iscsiadm -m session

 

[larsen]

Wie machst du das Discovery und was spuckt er denn da aus?

Wurde bei der Einrichtung vor ein paar Monaten so gemacht:

iscsiadm -m discovery -t sendtargets -p 10.0.3.140 -I iscsi_enp2s0f0 && \
iscsiadm -m discovery -t sendtargets -p 10.1.3.150 -I iscsi_enp2s0f1

Nur bei einem erneuten Discovery. Also eigentlich nur manuell oder beim Reboot.

D.h. selbst wenn ich das nun manuell lösche und es zunächst funktioniert, wird es immer wieder automatisch neu erstellt werden?

 

[larsen]

Um das zu prüfen, könntest du bitte die Ausgabe der folgenden beiden Kommandos posten?

atl-vm04:~# iscsiadm -m node
10.0.1.100:3260,1 iqn.1986-03.com.hp:storage.msa2040.15472745cf
10.0.1.100:3260,1 iqn.1986-03.com.hp:storage.msa2040.15472745cf
10.0.2.120:3260,3 iqn.1986-03.com.hp:storage.msa2040.15472745cf
10.0.2.120:3260,3 iqn.1986-03.com.hp:storage.msa2040.15472745cf
10.0.3.140:3260,5 iqn.1986-03.com.hp:storage.msa2040.15472745cf
10.0.3.140:3260,5 iqn.1986-03.com.hp:storage.msa2040.15472745cf
10.0.4.160:3260,7 iqn.1986-03.com.hp:storage.msa2040.15472745cf
10.0.4.160:3260,7 iqn.1986-03.com.hp:storage.msa2040.15472745cf
10.1.1.110:3260,2 iqn.1986-03.com.hp:storage.msa2040.15472745cf
10.1.1.110:3260,2 iqn.1986-03.com.hp:storage.msa2040.15472745cf
10.1.2.130:3260,4 iqn.1986-03.com.hp:storage.msa2040.15472745cf
10.1.2.130:3260,4 iqn.1986-03.com.hp:storage.msa2040.15472745cf
10.1.3.150:3260,6 iqn.1986-03.com.hp:storage.msa2040.15472745cf
10.1.3.150:3260,6 iqn.1986-03.com.hp:storage.msa2040.15472745cf
10.1.4.170:3260,8 iqn.1986-03.com.hp:storage.msa2040.15472745cf
10.1.4.170:3260,8 iqn.1986-03.com.hp:storage.msa2040.15472745cf

atl-vm04:~# iscsiadm -m session
tcp: [1] 10.0.3.140:3260,5 iqn.1986-03.com.hp:storage.msa2040.15472745cf (non-flash)
tcp: [2] 10.1.3.150:3260,6 iqn.1986-03.com.hp:storage.msa2040.15472745cf (non-flash)

 

[larsen]

Habe die nicht benötigten IPs/Verbindungen nun auf einem Host testweise entfernt und seitdem sind bisher keine weiteren Einträge im Log bzgl "no route to host" aufgetaucht. Neustart des Servers wird die Tage noch getestet, wenn es passt.

iscsiadm -m node -T ${IQN} -p 10.1.4.170 -I iscsi_enp2s0f0 -o delete
iscsiadm -m node -T ${IQN} -p 10.1.4.170 -I iscsi_enp2s0f1 -o delete
...

 

[larsen]

Auch nach einem Neustart keine weiteren Einträge mehr. Allerdings wüsste ich zu gerne, warum das auf einmal auftrat, denn nach der Einrichtung des SAN, die erst wenige Monate her ist, kam das noch nicht.