dm-multipath "ignoring map"

[r4pt0r]

Hallo,

Nachdem ich jetzt seit 3 Wochen nebenher mit Fibrechannel und multipath teste, geht mir langsam die Lust/Geduld aus. Zumindest mit linux... Grund ist dm-multipath. Das ist so ziemlich die unzuverlässigste Software die mir in den letzten Jahren untergekommen ist... Mittlerweile wundert es mich nicht mehr, dass kein Mensch Linux auf ernsthaften storage-systemen einsetzt...

Kurzer Überblick:
Am storageserver werden zvols per SCST als LUN exportiert, am initiator korrekt erkannt und jede LUN als 2 verschiedene device-nodes (sdX) angelegt. Das funktioniert absolut zuverlässig, solange ich jede LUN immer und nur über einen Pfad anfasse kann ich damit alles anstellen. Sinn macht das so aber nicht...

Jetzt kommt also multipath ins Spiel:
Ein "multipath -v2" erkennt erstmal _keines_ der multipath-devices, pfuscht dafür aber mit _sämtlichen_ lokalen Geräten herum und legt dafür bindings und wwnids an. Erst wenn man multipath explizit mit blacklisten und blacklist_exceptions dazu zwingt, schaut es sich die SCST-Geräte an.
Hat man "property "(ID_SCSI_VPD|ID_WWN|ID_SERIAL)"" in den exceptions nicht gesetzt kann man aber blacklisten und excepten so viel man will, die devnodes werden ignoriert. Diese regression durch einen Patch aus 2014 (!!!) findet man aber auch nur nach langem suchen in einem (ungelösten) Thema einer Mailinglist...

Hat sich multipath dann endlich zwingen lassen die richtigen devices zu mappen läuft es erstmal - bis man den Client neu startet, schief anschaut oder der Wind sich dreht...
Dann sind nämlich plötzlich die multipath-devnodes weg und es passiert nur noch folgendes:

Code: Alles auswählen

# multipath -d -v2
create: mpathb (26665663230363031) undef SCST_BIO,steam-fc
size=100G features='0' hwhandler='0' wp=undef
`-+- policy='queue-length' prio=1 status=undef
  |- 8:0:0:0 sdc 8:32 undef ready running
  `- 9:0:0:0 sde 8:64 undef ready running
create: mpathc (26566363634346334) undef SCST_BIO,test8
size=20G features='0' hwhandler='0' wp=undef
`-+- policy='queue-length' prio=1 status=undef
  |- 8:0:0:1 sdd 8:48 undef ready running
  `- 9:0:0:1 sdf 8:80 undef ready running

Im dry-run wird behauptet "alles erkannt"; ABER:

Code: Alles auswählen

# multipath -v2
Mar 23 19:15:44 | mpathb: ignoring map
Mar 23 19:15:44 | mpathc: ignoring map
Mar 23 19:15:44 | mpathb: ignoring map
Mar 23 19:15:44 | mpathc: ignoring map

Egal was man nun anstellt - flushen, Pfade entfernen/hinzufügen, maps reseten/resumen usw - multipath ignoriert die maps nur noch, startet sie aber nicht mehr. multipathd gibt ausser "ok", "fail" oder "error receiving packet" selbst mit -v99 nichts brauchbares aus - in den meisten Fällen einfach nur "fail" oder beendet/crasht kommentarlos

Ausschnitt von "multipath -v5":

Code: Alles auswählen

Mar 23 19:18:08 | mpathc: assembled map [0 0 1 1 queue-length 2 1 8:48 1 8:80 1]
Mar 23 19:18:08 | mpathc: set ACT_CREATE (map does not exist)
Mar 23 19:18:08 | mpathc: addmap [0 41943040 multipath 0 0 1 1 queue-length 2 1 8:48 1 8:80 1]
Mar 23 19:18:08 | libdevmapper: ioctl/libdm-iface.c(1786): device-mapper: reload ioctl on mpathc failed: Invalid argument
Mar 23 19:18:08 | mpathc: domap (0) failure for create/reload map
Mar 23 19:18:08 | mpathc: ignoring map
Mar 23 19:18:08 | mpathc: remove multipath map

Code: Alles auswählen

# multipathd show paths
hcil    dev dev_t pri dm_st chk_st dev_st  next_check
8:0:0:0 sdc 8:32  1   undef ready  running orphan    
8:0:0:1 sdd 8:48  1   undef ready  running orphan    
9:0:0:0 sde 8:64  1   undef ready  running orphan    
9:0:0:1 sdf 8:80  1   undef ready  running orphan  

Selbst neu exportieren der LUNs mit neuer WWN, damit multipath neue Geräte konfigurieren könnte, bringt nichts - scheinbar lädt multipath irgendwelchen Müll auf den LUNs ab, kann/will aber nichts mehr damit anfangen und kann seinen Dreck auch nicht zusammenkehren...

Das einzige was funktioniert: zvol direkt am Server mounten, Daten auf ein neues zvol kopieren und als neue LUN exportieren. Bis sich dm-multipath bei der nächstbesten Gelegenheit wieder zerlegt...


Hat sich hier noch jemand mit multipath befasst und ne Idee dazu? Oder Ist dm-multipath wirklich schlichtweg kaputt und verwaist (letzte Bewegung im Repository 2014...)? Ist dm-multipath die einzige Option und "status quo" für Linux und multipath?
Mal als Vergleich: mit FreeBSD erzeugt man mit "gmultipath label fooBar /dev/daX" ein Label auf jedem Device - fertig. Daran werden automatisch die einzelnen LUNs und Pfade erkannt und es läuft - völlig egal was man mit den LUNs anstellt, wie oft man neu startet und wieviele LUNs dazukommen oder entfernt werden. Da ist ja schon die Grundkonfiguration von dm-multipath mit den fehlerhaften/unvollständigen manpages ne Katastrophe dagegen...

[rendegast]

pfuscht dafür aber mit _sämtlichen_ lokalen Geräten herum und legt dafür bindings und wwnids

Diese /dev/disk/by-id/wwn....
habe ich hier auch, kommt von udev, 60-persistent-storage.rules.

scheinbar lädt multipath irgendwelchen Müll auf den LUNs ab, kann/will aber nichts mehr damit anfangen und kann seinen Dreck auch nicht zusammenkehren...

Das ließe sich klären mit einem (vorher) leeren Export und Hex-Vergleich.
Auch könnte udev das device vielleicht in einer persistent-Datei vermerkt haben.
Ala CD-Laufwerken und Netzwerk-Interfaces.

-F flush all unused multipath device maps

<->

-W reset the wwids file to only include the current multipath devices

?

device-mapper: reload ioctl on mpathc failed: Invalid argument

Vielleicht irgendwo ein Syntax-Fehler?
Unpassende Editoren fügen gerne mal control-character ein,
mal mcedit oder vim mit syntax-highlighting probieren.
Dazu die Datei mit einer Endung versehen, zBsp.
link.c -> multipath.conf
link.sh -> multipath.conf
und den Link aufrufen 'mcedit link.c'.




In der multipath.conf.annotated (jessie)

## name : blacklist
## scope : multipath & multipathd
## desc : list of device names to discard as not multipath candidates
## Devices can be identified by their device node name "devnode",
## their WWID "wwid", or their vender and product strings
## "device"
## default : fd, hd, md, dm, sr, scd, st, ram, raw, loop, dcssblk
##
#blacklist {
# wwid 26353900f02796769
# devnode "^(ram|raw|loop|fd|md|dm-|sr|scd|st)[0-9]*"
# devnode "^hd[a-z]"
# devnode "^dcssblk[0-9]*"
# device {
# vendor DEC.*
# product MSA[15]00
# }
#}
##
## name : blacklist_exceptions
## scope : multipath & multipathd
## desc : list of device names to be treated as multipath candidates
## even if they are on the blacklist.
## Note: blacklist exceptions are only valid in the same class.
## It is not possible to blacklist devices using the devnode keyword
## and to exclude some devices of them using the wwid keyword.
## default : -
##
#blacklist_exceptions {
# devnode "^dasd[c-d]+[0-9]*"
# wwid "IBM.75000000092461.4d00.34"
# wwid "IBM.75000000092461.4d00.35"
# wwid "IBM.75000000092461.4d00.36"
#}

Demnach sollte es erstmal scheinbar garnichts machen,
außer für /dev/sd*,
resp. das Behandeln von /dev/sd* wäre demnach so vorgesehen.
(obwohl das eine obsolete Doku sein könnte)


Vielleicht kommen die Probleme auch von
iscsitarget / istgt?

[r4pt0r]

Schonmal danke für die hilfestellungen, ich gehe mal einzeln drauf ein

Diese /dev/disk/by-id/wwn....
habe ich hier auch, kommt von udev, 60-persistent-storage.rules.

Die stören mich nicht - multipath trägt die WWNs und bindings in seinen configs (/etc/multipath/wwnid bzw bindings) ein; richtet also MP für CD-Laufwerk, USB-Stick und anderen Käse ein. Nur die devices die tatsächlich MP sind, ignoriert es gekonnt...

Das ließe sich klären mit einem (vorher) leeren Export und Hex-Vergleich.
Auch könnte udev das device vielleicht in einer persistent-Datei vermerkt haben.
Ala CD-Laufwerken und Netzwerk-Interfaces.

In keiner der "üblichen verdächtigen" Dateien von udev (NN_persistent-xy) werden die mp-geräte vermerkt. Auch sonst konnte ich nichts finden, ausser die beiden Dateien in /etc/multipath/
Würde mich aber nicht Wundern wenn multipath doch irgendwo heimlich still und leise (und natürlich ohne Hinweis in der doku...) noch was ablädt. Da aber das neu generieren der WWN nichts bringt, dafür aber das "austauschen" des blockdevices, tippe ich eher auf verstecktes brandmarken a la raid-controller...


-F, -f <device>, -W und auch manuelles leeren der wwids-file bringt nichts, die devices werden beim dry-run korrekt erkannt, dann aber mit "ignoring map" nicht mehr gemappt.

Vielleicht irgendwo ein Syntax-Fehler?
Unpassende Editoren fügen gerne mal control-character ein,
mal mcedit oder vim mit syntax-highlighting probieren.
Dazu die Datei mit einer Endung versehen, zBsp.
link.c -> multipath.conf
link.sh -> multipath.conf
und den Link aufrufen 'mcedit link.c'.

Wenn mir multipath verraten würde, was es da an den device-mapper funkt, der dann diese fehlermeldung zurückgibt... Aber das ist alles was ausgegeben wird.
An der multipath.conf liegt es nicht - die wird nicht angerührt und funktioniert ja mit neuen targets auch immer noch. multipath stößt das erstellen der mpathX-devicenodes über den devicemapper an, dabei wird aber irgendwas übergeben mit dem der DM nichts anfangen kann...
Ich hatte auch schon versucht den ablauf manuell per multipathd -k durchzugehen um evtl rauszufinden was genau schiefläuft - bei 'multipathd add map ...' bekomme ich aber höchstens ein "fail", meistens beendet multipathd einfach kommentarlos... verbosity-levels interessieren multipathd sowieso nicht (auch wenns in der manpage steht...) - mehr wie besagtes "ok", "fail" oder "error receiving packet" bekommt man auch mit -v99 nicht zurück...

Demnach sollte es erstmal scheinbar garnichts machen,
außer für /dev/sd*,
resp. das Behandeln von /dev/sd* wäre demnach so vorgesehen.
(obwohl das eine obsolete Doku sein könnte)

Die kommentierte Konfigurationsdatei ist leider genau wie die manpages und doku obsolet bzw fehlerhaft. Damit die exceptions funktionieren, muss auch 'property "(ID_SCSI_VPD|ID_WWN|ID_SERIAL)"' gesetzt werden. Das hat mich 2 Abende gekostet das rauszufinden...

Code: Alles auswählen

Vielleicht kommen die Probleme auch von
iscsitarget / istgt?

iSCSI kommt nicht zum Einsatz, die LUNs werden am target per SCST direkt als SCSI-device über FC abgebildet. Ein FreeBSD-initiator läuft tadellos an den beiden anderen Ports des HBAs am Server (bootet sogar von LUNs) - das Serverseitige Setup passt IMHO.
Am debian-initiator läuft ausser dem qla2xxx-Kernelmodul ebenfalls keinerlei störende Zwischenschicht. Das FC/SCST-Setup läuft auch absolut zuverlässig, die Pfade werden immer sauber erkannt, devicenodes (auch by-id und by-partlabel) werden korrekt angelegt und ich kann mit jedem Pfad normal arbeiten. Selbst ein ZFS-Pool der über den mp-devicenode angelegt wurde funktioniert noch immer einwandfrei über beide Pfade.
Es ist nur dm-multipath das konstant Probleme macht...

[rendegast]

Hat man "property "(ID_SCSI_VPD|ID_WWN|ID_SERIAL)"" in den exceptions nicht gesetzt kann man aber blacklisten und excepten so viel man will, die devnodes werden ignoriert.
...
# multipath -d -v2
create: mpathb (26665663230363031) undef SCST_BIO,steam-fc
...
create: mpathc (26566363634346334) undef SCST_BIO,test8

Ich habe jetzt auch herumprobiert

Code: Alles auswählen

blacklist {
  #devnode "*"     FALSCH, nicht regex genug, Fehler in README.Debian
  devnode ".*"
}
blacklist_exceptions {
   wwid "...."
}

funktioniert so nicht, so auch in dem Ausschnitt der kommentierten conf oben.
Also

Code: Alles auswählen

blacklist {
  wwid ".*"
}
blacklist_exceptions {
   wwid "WDC_WD2000"
}

um nur meine WD 2TB "durchzulassen".

Bei Dir demnach

Code: Alles auswählen

defaults {
  user_friendly_names true
}
blacklist {
  wwid ".*"
}
blacklist_exceptions {
   #wwid "mpatha"              NEIN
   wwid "26665663230363031"
   wwid "26566363634346334"
}

wobei Dein Weg über die property allgemeiner ist.
Ginge aber wohl auch ein wwid-regex für einen reinen Zahlenausdruck.

Insoweit eigentlich valides Verhalten.

Und nach einer Änderung halt auch immer

Code: Alles auswählen

[systemctl stop multipath-tools.service]
multipath -F
multipath -W
[systemctl [re]start multipath-tools.service]

(was bei meinen Tests einfach geht, da ich diese mappings sonst nicht benutze)

Die Datei bindings hat dabei einen persistent-Charakter und bleibt erhalten,
wogegen die Datei wwids entsprechend neu geschrieben wird.
An den devices scheint mir keine Änderung stattzufinden,
das passiert wohl erst, wenn mit mdadm oder lvm daran herumgebastelt wird.

# multipath -v2
Mar 23 19:15:44 | mpathb: ignoring map
Mar 23 19:15:44 | mpathc: ignoring map
Mar 23 19:15:44 | mpathb: ignoring map
Mar 23 19:15:44 | mpathc: ignoring map

Stimmt dann noch die Datei bindings?
Wie ist es ohne user_friendly_names?

[r4pt0r]

Bei Dir demnach

Code: Alles auswählen

defaults {
  user_friendly_names true
}
blacklist {
  wwid ".*"
}
blacklist_exceptions {
   #wwid "mpatha"              NEIN
   wwid "26665663230363031"
   wwid "26566363634346334"
}

wobei Dein Weg über die property allgemeiner ist.
Ginge aber wohl auch ein wwid-regex für einen reinen Zahlenausdruck.

Da das ganze primär auch zum testen und VMs zwischen 2 hosts austauschen gedacht ist, soll alles was über SCST_BIO reinkommt erkannt werden - damit neue LUNs nicht immer von Hand in die exceptions geschrieben werden müssen.

Die Datei bindings hat dabei einen persistent-Charakter und bleibt erhalten,
wogegen die Datei wwids entsprechend neu geschrieben wird.
An den devices scheint mir keine Änderung stattzufinden,
das passiert wohl erst, wenn mit mdadm oder lvm daran herumgebastelt wird.

# multipath -v2
Mar 23 19:15:44 | mpathb: ignoring map
Mar 23 19:15:44 | mpathc: ignoring map
Mar 23 19:15:44 | mpathb: ignoring map
Mar 23 19:15:44 | mpathc: ignoring map

Stimmt dann noch die Datei bindings?
Wie ist es ohne user_friendly_names?

Mit mdadm oder LVM wird an den LUNs nichts gebaut - zumindest nicht von mir. Was ggf multipath über den devicemapper veranstaltet habe ich noch nicht eroiert, hier scheint aber der Wurm drin zu sein (siehe weiter unten...)

user_friendly_names yes/no ändert auch nichts.

Die bindings bleibt bei mir auch erhalten - trotzdem werden die maps ignoriert. Auch komplettes leeren der bindings ändert nichts...

Mir kommt es solangsam so vor als würde der devicemapper und/oder multipath sich irgendwo auf die sdX-devicenodes stützen und bei neuer Zuordnung fliegt das dann in die Luft. Solange ich nämlich immer mehr LUNs hinzufgefügt habe (und damit neue sdX-nodes erzeugt werden), funktionierten die jeweils neusten LUN(s).
Werden LUNs entfernt oder ausgetauscht, funktionieren diese nichtmal wenn sie völlig neu erstellt sind (am target)!

Habe gerade sämtliche LUNs deaktiviert, ein neues zvol erstellt und als LUN0 aktiviert - am initiator wird diese nach einem rescan jetzt als sdc und sdd erkannt. wwnid und bindings sind geleert, multipath frisch gestartet, trotzdem:

Code: Alles auswählen

# multipath -v2
Mar 25 17:14:24 | mpatha: ignoring map
Mar 25 17:14:24 | mpatha: ignoring map

Auch mit

Code: Alles auswählen

multipaths {
    multipath {
        wwid        26232383136386465
        alias       asdf
    }   
}

in der /etc/multipath.conf werden diese ignoriert.

snippet von multipath -v10:
https://zerobin.rostwald.de/?e1c781065a ... cgPQcrG90=

Wenn ich das richtig deute, werden die maps erstellt und multipath weist dm nochmal an die map neu zu laden, übergibt dabei aber irgendwas das dem devicemapper nicht passt:

Code: Alles auswählen

Mar 25 17:25:18 | libdevmapper: ioctl/libdm-iface.c(1768): dm reload asdf OF [16384] (*1)
Mar 25 17:25:18 | libdevmapper: ioctl/libdm-iface.c(1786): device-mapper: reload ioctl on asdf failed: Invalid argument